debuginfo: Add a rust-gdb shell script for starting GDB with Rust pretty printers

[michaelwoerister]

This pull request adds the rust-gdb shell script which starts GDB with Rust pretty printers enabled. The PR also makes rustc add a special .debug_gdb_scripts ELF section on Linux which tells GDB that the produced binary should use the Rust pretty printers.

Note that at the moment this script will only work and be installed on Linux. On Mac OS X there's rust-lldb which works much better there. On Windows I had too many problems making this stable. I'll give it another try soonish.

You can use this script just like you would use GDB from the command line. It will use the pretty printers from the Rust "installation" found first in PATH. E.g. if you have ~/rust/x86_64-linux-gnu/stage1/bin in your path, it will use the pretty printer scripts in ~/rust/x86_64-linux-gnu/stage1/lib/rustlib/etc.

[michaelwoerister]

I've looked into this over the last few days and the problem is that the compiler doesn't like the inline assembly on Android. @luqmana already mentioned that he thought the assembly to look a bit flaky at the work week.
I've been trying to implement adding the .debug_gdb_scripts in a more stable, platform independent way, which turned out to be more work than expected because the linker likes to through out 'unused' stuff. The most promising approach so far seems to be to go the libmorestack-route: Compile a small static library containing only the ELF section in question and then linking that with --whole-archive. I hope to have implemented this soon. Unfortunately this will mean some more specialized targets in the makefiles :/

[michaelwoerister]

OK, I've updated this and tested it on Windows, Linux, and OSX. Let's see how it fares on Android. I'm not using any assembly code anymore, just a global variable placed in a special section. I also modified the main-function shim to reference this global so that the linker doesn't kick it out. This turned out to be the only way of getting the section through the --gc-sections linker pass, which we enable for executables.

@alexcrichton, you wanna take another look at this?

[alexcrichton]

I thought we had a better way for keeping the section despite --gc-sections as metadata isn't stripped in dylibs somehow, but sadly I was wrong.

This seems like a pretty non-invasive solution, and we can always tinker with slightly more elegant methods later :)

[michaelwoerister]

Yes, the cleanest way to keep the section in is probably to use the KEEP directive in the linker script. But since we don't use custom linker scripts, I didn't want to go down that road...