This is the mail archive of the
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: Tue, 04 Dec 2012 16:02:00 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
Forgot to reply to this earlier. Wanted to test some things on ppc64
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
Breakpoint 1, get_tty_state () at jobs.c:2001
#0 get_tty_state () at jobs.c:2001
#1 0x000000001004e9b4 in initialize_job_control (force=<optimized out>)
#2 0x000000001001f108 in shell_initialize () at shell.c:1725
#3 0x000000001001cd48 in main (argc=1, argv=0xffffffff278, env=0xffffffff288)
I do think that is correct and also what a user expects when translating
an address to a name (through dwfl_module_addrname).