Change:
use syntax::codemap::Span; use syntax::parse::token; <ins> // RLIB LLVM-BYTECODE OBJECT LAYOUT // Version 1 // Bytes    Data // 0..10    "RUST_OBJECT" encoded in ASCII // 11..14   format version as little-endian u32 // 15..22   size in bytes of deflate compressed LLVM bitcode as //          little-endian u64 // 23..     compressed LLVM bitcode // This is the "magic number" expected at the beginning of a LLVM bytecode // object in an rlib. pub static RLIB_BYTECODE_OBJECT_MAGIC: &'static [u8] = b"RUST_OBJECT"; // The version number this compiler will write to bytecode objects in rlibs pub static RLIB_BYTECODE_OBJECT_VERSION: u32 = 1; // The offset in bytes the bytecode object format version number can be found at pub static RLIB_BYTECODE_OBJECT_VERSION_OFFSET: uint = 11; // The offset in bytes the size of the compressed bytecode can be found at in // format version 1 pub static RLIB_BYTECODE_OBJECT_V1_DATASIZE_OFFSET: uint = RLIB_BYTECODE_OBJECT_VERSION_OFFSET + 4; // The offset in bytes the compressed LLVM bytecode can be found at in format // version 1 pub static RLIB_BYTECODE_OBJECT_V1_DATA_OFFSET: uint = RLIB_BYTECODE_OBJECT_V1_DATASIZE_OFFSET + 8; </ins> #[deriving(Clone, PartialEq, PartialOrd, Ord, Eq)] pub enum OutputType { OutputTypeBitcode,

Discussion:
There's another bug in LLDB that causes it to segfault when reading archive files. This one has already been fixed in May () but it still exists in a lot of LLDB binaries out there. As far as I can tell, the bug occurs when a number of object files are stored in an archive and the last one ends at an uneven byte offset. This often seems to be the case for compressed byte-code archives in rlibs (maybe regular object files are always padded to an even size?). I'm currently compiling a possible workaround (pad the bytecode objects to an even size). It would be good if we could allow for rust code to be debugged with older LLDB versions too.
Update: Padding all archives entries to an even size seems to prevent the crash in LLDB and I have not seen any detrimental side effects to this approach so far. Any idea if the additional padding byte at the end of the compressed LLVM IR object in an archive could potentially lead to a problem?
I'm not familiar enough with the format of object files or bytecode files to know whether an extra byte or two at the end would corrupt them, but if it's working ok currently then I'd just ship it!
I doubt that the containing archive will care about the padding byte, but either the decompression algorithm or the LLVM bitcode reader could trip over it. The safe way to do this would probably be to prepend the actual size of the compressed data, so we always know how much data to pass to . I guess, I'll implement this and make a pull request.
Thinking about it, changing the format here is not as so trivial since the compiler must handle libs with the old format differently from libs with the new format. I see two options: (1) Just add the padding byte and hope for the best (2) Introduce some kind of header (including a version byte) before the compressed bitcode, in order to future-proof this against other changes to the encoding. I think I'd favor option (2).
Is this only a problem for the bytecode in archives, or is it also a problem for object files?
So far it has only occurred for bytecode. All object files I came across had a size dividable by 2. I don't know if that's a coincidence...
Interesting!

I'm all for putting the bytecode in whatever format we want (it's already just a huge deflated stream)
I'll come up with something and then we can discuss the matter further when we have some code to look at in a PR, OK?
Sounds good to me!