debuginfo: Add GDB pretty printers for structs and enums.

[michaelwoerister]

Also extends the autotest framework to let a test case choose if pretty printing should be enabled.

[alexcrichton]

Is the pretty printer file also something that we should be installing with rust itself? If so, where to?

[michaelwoerister]

Yes that would be a good idea but we need to do a few things in order for GDB to actually use the pretty printers:

1. The folder containing the pretty printer Python module must be in PYTHONPATH for the GDB instance, so the Python runtime can find it.
2. There are 2 ways of telling GDB to use a pretty printer automatically:
   1. There has to be a file next to the executable/dynlib with the same name + -gdb.py. GDB will automatically load and execute this file when the binary is loaded--iff the file is in GDB's auto-loading safe path. This file is normally used to load and register the pretty printer. The pretty printer module too has to be in the auto-loading safe path.
   2. The second option of telling GDB to use the pretty printer is via a special .debug_gdb_scripts section in the binary. This section must contain a list of scripts to load, among which the activation of the pretty printer can be.

So, in order to make this usable, we need to make sure that the pretty printer Python modules is added to some location in the Rust installation then make sure to add these locations to GDB auto-loading safe path. I guess the best way to do this would be to provide a shell-script that starts GDB with the additional needed parameters (see the scripts the autotesting framework creates). You would then call GDB via rgdb ... to start it in Rust mode. Alternatively we could let make install modify ~/.gdbinit to always add the directories to the safe path, but I think that's a bit intrusive.

We would also have to make sure that rustc either creates the auto-loading script or adds the .debug_gdb_scripts section to the executable. I'm not sure yet, which of these is the better option.

[alexcrichton]

Ok, sounds like we should try to tackle installation at a later date.

[brson]

Added installation issue #16365

[michaelwoerister]

Hm, it seems that the GDB version on the build infrastructure doesn't support the -iex commandline option yet. I'll see if I can work around that limitation...

[michaelwoerister]

The problem with -iex could be solved but this still is all a bit more fiddly than I expected: The buildbots (at least those serving the try branch) are using GDB 7.4 which does not yet support the auto-load safe-path commands. I guess it would just load anything without any safety checks. The problem is that GDB aborts when it encounters the unknown command, thus failing the test.
I guess we have to try and find out the actual GDB version and generate different command files depending on that...

[michaelwoerister]

Well, it seems that in GDB 7.4 one can't access anonymous fields from Python yet, so that means we can't support tuples there.
I guess the best way to cope with this is to split out test cases that depend on newer features and ignore them when not supported. I'll do some more testing to see if any other things need to be handled this way.

[michaelwoerister]

OK, this works on the try branch now. I've added the possibility to require a minimum GDB version for debuginfo tests. If the GDB version used is too low, the test is ignored.
For now, there are two separate GDB pretty printer test cases, one that only tests things that older GDB versions can handle (which excludes tuples and enums) and a second one that does more exhaustive testing.
Unfortunately, it's not really straightforward to reliably find out GDB's version, as the version string can have different formats. On the test bots on OSX it's:

GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)

On the linux build bot it seems to be:

(7.4-2012.04-0ubuntu2)

And locally on my machine it's:

GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7

This will definitely need some more work in the future. I'm not sure if this is ready to merge yet :/

[michaelwoerister]

This is obviously still inadequate as it yields 2.04 for the version string on the build bots, which is probably something like GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04...

[brson]

Here's what's on the main Linux slaves:

gdb ubuntu@ip-10-199-139-133:~$ gdb --version
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.

[michaelwoerister]

OK, I've updated this. It appears that sed does not behave the same on Linux and OSX, so I pulled the GDB version extraction into compiletest. The extraction algorithm can now handle all GDB version string formats I have seen so far (including the one on my local Windows installation), so this should be good to go.