This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: linker debug info editing


On Fri, 2006-03-10 at 04:49, Alan Modra wrote:
> This is a first pass at debug info editing to remove bogus entries for
> link-once functions.

There is an equivalent gcc solution we could consider.  Create a
separate compilation unit die for each linkonce function.  We could use
section groups to tie the debug info to the linkonce function, so that
the debug info disappears along with the function.

We already have a similar scheme in use for header files, that mirrors
the BINCL/EINCL stabs support.  This was one of the new features that
went into the DWARF3 standard.  Unfortunately, this code is not the
default yet.  You have to specify -feliminate-dwarf2-dups to get it.  I
think there was some gdb work that needed to be done to complete the
project, and us gcc developers aren't very good at volunteering to do
gdb work.

Using a similar approach for linkonce functions would probably also
require some gdb work.  For one thing, we would have a lot more
compilation unit dies than we had before (worst case one per function
instead of one per file), and gdb might not be able to handle that.

Checking the DWARF3 standard, it specifically mentions elimination
function duplications in Appendix E, in section E.4.2.  Appendix E
describes how to use multiple compilation units and section groups to
eliminate duplication debug info.

If we do need link time editing of dwarf2 debug info, there is a lot of
useful stuff that could be done here, such as eliminating duplicate
debug_abbrev entries.  This is probably more complicated than what you
are attempting here though, but it could perhaps be added later on top
of your work.

You mentioned a bunch of assumptions in the code.  Those assumptions
should be tested against some compilers other than gcc.  Testing the
Intel compiler might not be too hard for instance, especially if you can
get HJ to do it for you.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]