This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 19 Nov 2012 20:29:31 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Mon, Nov 19, 2012 at 09:19:52AM -0500, Frank Ch. Eigler wrote:
> Hi -
>
> On Mon, Nov 19, 2012 at 01:53:12PM +0100, Mark Wielaard wrote:
> > [...]
> > > > > (gdb) bt
> > > > > #0 0x00000000100004d0 in .f ()
> > > > > #1 0x0000000010000500 in .main ()
> > [...]
> > But I don't see why that has to leak through to the user in a backtrace
> > where they just want to know which function name corresponds to a
> > specific address. The extra dot doesn't add any value in this case and
> > is just confusing.
>
> Not entirely -- the two locations are distinct, and a breakpoint can
> pass through one and not the other, which could make a difference to
> certain low-level debugging tasks.
I am not sure I follow how this would work.
A function descriptor symbol doesn't point to executable code, just
to some data that describes the function and where its entry point is.
Or do you mean someone could place a data watchpoint on it?
I don't think that will be easily confused, even when doing such low
level debugging.
But my point was more that in a backtrace it is more natural to
associate the actual function name with the address of the code
than prefixing it with an artificial dot.
Cheers,
Mark