Re: External debug symbols

[Alexander Larsson <alexl@redhat.com>]

On 21 Aug 2002, Jim Blandy wrote:

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

Since I don't know much about the gdb codebase I tried to look for the 
solution that required the smallest amount of changes. But yeah, I was 
also a bit amazed how easy it was.
 
> 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.

It does sound nice, but it also sounds like an load of work. And for us 
having just one file with debug information per lib/executable is actually 
preferable, from a packagaging perspective.
 
> 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 will change that.
 
> 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.

The later problem could be fixed by having a back-pointer from the debug 
objfile to the original one, and NULLing out the other pointer when the 
debug objfile is freed.

The first issue sounds harder. It could be handled by making sure the 
debug file is always in front of the original file in the object_files 
list. But that sounds somewhat fragile.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a notorious chivalrous cowboy on his last day in the job. She's a 
disco-crazy paranoid vampire looking for love in all the wrong places. They 
fight crime!