debuginfo: LLDB segfaults for some archives containing padding bytes at the end.

[michaelwoerister]

There's another bug in LLDB that causes it to segfault when reading archive files. This one has already been fixed in May (llvm-mirror/lldb@e7e7a50) 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.

[michaelwoerister]

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.
@brson @alexcrichton @luqmana 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?

[alexcrichton]

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!

[michaelwoerister]

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 deflate. I guess, I'll implement this and make a pull request.

[michaelwoerister]

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).

[alexcrichton]

Is this only a problem for the bytecode in archives, or is it also a problem for object files?

[michaelwoerister]

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...

[alexcrichton]

Interesting! I'm all for putting the bytecode in whatever format we want (it's already just a huge deflated stream)

[michaelwoerister]

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?

[alexcrichton]

Sounds good to me!