Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifix.com>
To: Alan Modra <amodra@bigpond.net.au>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: linker debug info editing
Date: Fri, 10 Mar 2006 20:06:00 -0000	[thread overview]
Message-ID: <1142020201.13901.29.camel@aretha.corp.specifix.com> (raw)
In-Reply-To: <20060310124921.GN6777@bubble.grove.modra.org>

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


  reply	other threads:[~2006-03-10 19:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-10 19:44 Alan Modra
2006-03-10 20:06 ` James E Wilson [this message]
2006-03-10 20:16   ` Daniel Jacobowitz
2006-03-12  7:58 ` Jim Blandy
2006-03-13 12:53   ` Daniel Berlin
2006-03-13 20:19     ` Alan Modra
2006-03-14 15:10     ` Daniel Berlin
2006-03-13  4:59 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1142020201.13901.29.camel@aretha.corp.specifix.com \
    --to=wilson@specifix.com \
    --cc=amodra@bigpond.net.au \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox