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