[patch] Resolve ppc64 func descriptors as .func (via .opd)

Mark Wielaard mjw at redhat.com
Tue Dec 4 15:02:00 UTC 2012


Hi Jan,

Forgot to reply to this earlier. Wanted to test some things on ppc64
first.

On Tue, 2012-11-20 at 14:15 +0100, Jan Kratochvil wrote:
> On Mon, 19 Nov 2012 20:29:31 +0100, Mark Wielaard wrote:
> > 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?
> 
> "break" command puts code execution breakpoint to whatever linespec you gave
> to it.  Some autodetection of symbol types would be confusing to users.
> (The last sentence may be a subject for discussion but GDB generally behaves
> that way.)

When I use gdb on a ppc64 binary (bash in this case), it handles
function names normally as I expect (without needing to prefix a dot).

(gdb) break get_tty_state
Breakpoint 1 at 0x1004ced0: get_tty_state. (2 locations)

> > 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.
> 
> When we were designing new arch/ABI that is a nice idea.  But ppc64 ABI is
> what it is, I do not think elfutils should confuse it even more it already is.

I don't think this has anything to do with the ppc64 ABI. We are
interested in translating addresses to function/code location names. And
in gdb backtraces look normal too, again without any unnecessary
dot-prefixes:

Breakpoint 1, get_tty_state () at jobs.c:2001
2001	{
(gdb) where
#0  get_tty_state () at jobs.c:2001
#1  0x000000001004e9b4 in initialize_job_control (force=<optimized out>)
    at jobs.c:3734
#2  0x000000001001f108 in shell_initialize () at shell.c:1725
#3  0x000000001001cd48 in main (argc=1, argv=0xffffffff278, env=0xffffffff288)
    at shell.c:568

I do think that is correct and also what a user expects when translating
an address to a name (through dwfl_module_addrname).

Cheers,

Mark



More information about the elfutils-devel mailing list