Add workaround for archive reading bug in LLDB.

[michaelwoerister]

LLDB contains a bug that makes it crash if an archive it reads contains a file the name of which is exactly 16 bytes long. This bug recently has made it impossible to debug Rust applications with LLDB because some standard libraries triggered it indirectly:
For rlibs, rustc includes the LLVM bytecode in the archive, giving it the extension ".bc.deflate". For liballoc (for example) this results in the 16 character filename "alloc.bc.deflate", which is bad.

This commit replaces the ".bc.deflate" suffix with ".bytecode.deflate" which itself is already longer than 16 bytes, thus making sure that the bug won't be run into anymore.

The bug could still be run into with 14 character filenames because then the .o files will trigger it. However, this is much more rare and working around it would introduce more complexity than necessary at the moment. It can always be done later on, if the need arises.

Fixes #14356.

Q: Should we try to stay backwards compatible by looking for xxx.bc.deflate if xxx.bytecode.deflate is not found?

[alexcrichton]

Does LLDB die with any file exactly 16 characters? Whenever we suck in a native static library we prefix their object files with r-<libname>- to disambiguate the same-name object files across libraries. Would those also cause trouble with LLDB?

[michaelwoerister]

Yes, I'm pretty sure that could also trigger the crash. The offending code can be found here:
https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp#L108
If you know of a library/objectfile that you think will trigger the bug, then it should be easy to test. Every LLDB version contains the bug and I don't think anything has to be compiled with debuginfo enabled. Just start LLDB, and set a breakpoint. I'm not sure you actually have to run the program. I have not investigated the exact circumstances that trigger the bug. However, my LLDB autotests (compiled with --prefer-dynamic) all ran into it.

[alexcrichton]

It looks like it is indeed a problem: https://gist.github.com/alexcrichton/99dc5ed5400268ab0ed2. When I try to set a breakpoint LLDB dies.

The problem is that whenever we suck in object files from library foo, we prefix them all with r-foo-, so in this case we're making an rlib with the object file r-foobar-fooba.o (exactly 16 characters). Neither foobar nor fooba are that long of names, so this may actually crop up occasionally.

Perhaps we could just unconditionally rename files if they're 16 letters long? Something along the lines of:

• If you insert a new file in an archive with exactly 16 characters, prepend XX to the front.
• If you read a file from an archive with exactly 16 characters, look for the file with XX in front.

I think we're only reading our own archives, so that should work for now.

[alexcrichton]

Ah, and a transcript of my LLDB crash:

$ make   
gcc -c foobar.c -o fooba.o
ar crus libfoobar.a fooba.o
rustc foo.rs -L.
rustc bar.rs -L.
$ lldb ./bar      
Current executable set to './bar' (x86_64).
(lldb) b main
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: basic_string
zsh: abort      lldb ./bar

[michaelwoerister]

Ah, and a transcript of my LLDB crash [...]

Yes, that's the one. If we know all points where files are added and read from archives then just adding some prefix if needed is certainly a good idea. Fixing the r-<libname>- thing only is even easier. Just use something that will always make the name longer than 16 bytes, like rust-qualified-<libname>-, which admittedly is a bit ugly :).

If we go down the smart-prefixing approach, which I prefer if we can make it work reliably, then it would probably be a good idea to make the prefix something that points to the problem it solves, like lldb-fix-. That would allow someone stumbling upon the strange, unexpected name to search rustc's code base and find out what this is all about.

[alexcrichton]

Hm, I think I prefer the more principled strategy of not just throwing prefixes everywhere.

I like your strategy of lldb-fix-r-<libname>-foo.o (or something like that)

[michaelwoerister]

That means checking if something would end up with a 16-byte filename and only then prepending llidb-fix-, right?

[alexcrichton]

Sounds good to me, yeah. Once an object file has been included, we never look at it again (except to perhaps shuffle it into a staticlib), so we can name it whatever we want.

[michaelwoerister]

OK, I'll look into it and update this PR. However, I can't say if I'll have time for this before Wednesday, next week. If you decided this was a small enough fix to do yourself before that, I certainly wouldn't object.

[alexcrichton]

Ok, thanks! I'll take over and push an update for the included object files as well.

[alexcrichton]

Continued in #14683

[michaelwoerister]

Thanks for taking over :)