Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Roland McGrath <roland@hack.frob.com>
Cc: elfutils-devel@lists.fedorahosted.org, binutils@sourceware.org,
	       gdb-patches@sourceware.org
Subject: Re: [2/3, ppc64, elfutils patch] eu-strip vs. func addresses for GDB inferior calls
Date: Wed, 23 Mar 2011 18:05:00 -0000	[thread overview]
Message-ID: <20110323172132.GA18225@host1.jankratochvil.net> (raw)
In-Reply-To: <20110323164736.716252C1B1@topped-with-meat.com>

Hi Roland,

On Wed, 23 Mar 2011 17:47:36 +0100, Roland McGrath wrote:
> What's the rationale for including the .opd section in the .debug file?

the synthetic `.funcname' instructions-pointing symbols are generated on ppc64
by BFD on its own from the function descriptor ELF symbols `funcname'.
(DWARF symbols `funcname' point to the instructions which may be confusing.)

BFD has no idea about the linkage of the binary and the .debug BFD files.
Only GDB connects the binary and the .debug BFD files content for the user.

IIUC there would be needed some new API part to generate the synthetic symbols
in cooperation with GDB providing the BFD files .debug_link read out linkage
to the BFD synthetic functions producer.


> It is really just like any other text or data.  

I agree it is only a workaround of the BFD design.  For libc.so.6 2172512
bytes the .opd section is 42472 bytes (1.95%).


> Why can't you use the symbols
> from the .debug file and read the data from the main file just like you do
> for "p initialized_variable" or "disas function" without an inferior?

`p'/`disas' are GDB functionality.  `.funcname' symbols are BFD functionality.


Thanks,
Jan


  reply	other threads:[~2011-03-23 17:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23 15:49 Jan Kratochvil
2011-03-23 17:16 ` Roland McGrath
2011-03-23 18:05   ` Jan Kratochvil [this message]
2011-03-24  3:09     ` Alan Modra
2011-04-04 11:19       ` obsolete: " Jan Kratochvil
2011-03-24 10:44     ` Roland McGrath
2011-03-23 22:18 ` Ulrich Drepper

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=20110323172132.GA18225@host1.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=elfutils-devel@lists.fedorahosted.org \
    --cc=gdb-patches@sourceware.org \
    --cc=roland@hack.frob.com \
    /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