Re: External debug symbols

[Jim Blandy <jimb@redhat.com>]

Wow, that's a lot less work than I expected it to be.  It doesn't look
especially wrong to me.  Basically, the presence of a .debuglink
section tells GDB that, whenever it loads one objfile, it should also
load the other.  When the stripped objfile is freed, the other one is
freed, too.

Sun's toolchain, I'm told, has the ability to simply leave the debug
info in the .o files, and just put what amounts to an index in the
executable file.  The debugger is responsible for figuring out which
.o file has the data it needs, and applying any relocs to the debug
info based on the symbol values in the linked executable.  This makes
linking a lot faster, and keeps executables small.  This would also
address your distribution size problem, but it would also be helpful
to developers in their everyday work as well.

But since the .debuglink change is so simple, it seems a shame to put
that on hold in favor of an alternative solution which I expect will
take a lot more work, and may never get done.

.debuglink looks like a Dwarf 2 section name.  How about .gnu_debuglink?

I'm also concerned about the deallocation policy.  I think your change
will break the ALL_OBJFILES_SAFE macro, since the `nxt' pointer the
macro carefully caches before evaluating the `for' body will become
invalid if the body goes and frees the objfile it points to.

Along similar lines --- what would happen if the debug objfile gets
unloaded before the stripped objfile?  Wouldn't the stripped objfile
still have a dangling pointer to the now-gone debug objfile?  I can't
think of a situation where this would happen, but it would be nice to
be confident that it didn't matter.

Alexander Larsson <alexl@redhat.com> writes:

> Hi
> 
> I've been experimenting some with removing debug information from binaries 
> and placing it in a separate file, and then having gdb automatically load 
> these if availible. (The goal here is to package debug information in 
> separate packages that can be on-demand downloaded and installed.)
> 
> I have written a libelf based application that takes an elf file, splits 
> out debug information to a separate file, strips the original file and 
> adds a ".debuglink" section to the stripped file. This section contains 
> the basename of the filename of the debug file and a crc32 checksum of it.
> 
> I've also written an "unstrip" application that puts together the original 
> ELF file from the stripped one and the debug file (and some extra 
> information I put in a section of the debug file). This produces a bitwise 
> identical file to the original.
> 
> My next step is to make gdb automatically follow ".debuglink" sections so 
> that i don't have to use the unstrip application. Attached to this mail is 
> a patch that implements a "badhack" which seems to almost work. In order 
> for it to work I had to add all the original section headers to the debug 
> file (but SHT_NOBITS, so they take no space). It seems to work for the 
> main binary, but setting breakpoints in libraries doesn't work. I think it 
> gets the base address wrong or something.
> 
> What are your opinions about this solution? Has anything like this been 
> done or tought of before? I'm pretty scared of the gdb codebase (looked at 
> it for the first time today), so my solution is probably both buggy and 
> generally wrong, tips of other ways to do this are appreciated.
> 
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl@redhat.com    alla@lysator.liu.se 
> He's a benighted Jewish romance novelist plagued by the memory of his family's 
> brutal murder. She's a time-travelling Bolivian traffic cop with only herself 
> to blame. They fight crime!