gdb disassembling __pthread_getspecific (was Re: pthread impl detection)
gdb disassembling __pthread_getspecific (was Re: pthread impl detection)
- Subject: gdb disassembling __pthread_getspecific (was Re: pthread impl detection)
- From: Jim Ingham <email@hidden>
- Date: Tue, 21 Dec 2004 13:18:31 -0800
I think it is just that the symbol is there, but the code doesn't get
loaded till the program runs. So for instance:
inghji:tot-shlib-experiment/build/gdb > ./gdb ./gdb
GNU gdb 2004-03-03-cvs (Mon Nov 15 19:54:46 GMT 2004)
...
(top-gdb) disassemble __pthread_getspecific
Dump of assembler code for function ___pthread_getspecific:
0xffff82c0 <___pthread_getspecific+0>: nop
0xffff82c4 <___pthread_getspecific+4>: .long 0x0
0xffff82c8 <___pthread_getspecific+8>: .long 0x0
0xffff82cc <___pthread_getspecific+12>: .long 0x0
0xffff82d0 <___pthread_getspecific+16>: .long 0x0
0xffff82d4 <___pthread_getspecific+20>: .long 0x0
0xffff82d8 <___pthread_getspecific+24>: .long 0x0
0xffff82dc <___pthread_getspecific+28>: .long 0x0
End of assembler dump.
(top-gdb) break main
Breakpoint 3 at 0x2350: file ../../gdb/src/gdb/gdb.c, line 30.
(top-gdb) run
Starting program:
/Volumes/ThePlayground/Users/jingham/Work/gdb-sources/tot-shlib-
experiment/build/gdb/gdb
Reading symbols for shared libraries . done
Breakpoint 3, main (argc=1, argv=0xbffff29a) at
../../gdb/src/gdb/gdb.c:30
30 memset (&args, 0, sizeof args);
(top-gdb) disassemble __pthread_getspecific
Dump of assembler code for function ___pthread_getspecific:
0xffff82c0 <___pthread_getspecific+0>: rlwinm r5,r3,2,0,29
0xffff82c4 <___pthread_getspecific+4>: mfspr r3,259
0xffff82c8 <___pthread_getspecific+8>: add r5,r5,r4
0xffff82cc <___pthread_getspecific+12>: lwzx r3,r3,r5
0xffff82d0 <___pthread_getspecific+16>: blr
0xffff82d4 <___pthread_getspecific+20>: .long 0x0
0xffff82d8 <___pthread_getspecific+24>: .long 0x0
0xffff82dc <___pthread_getspecific+28>: .long 0x0
End of assembler dump.
Not much we can do about this...
Jim
On Dec 21, 2004, at 12:04 PM, email@hidden wrote:
On 12/20/04 Eric Albert wrote:
On Dec 20, 2004, at 7:26 AM, Paolo Molaro wrote:
the best implementation for the specific hardware in use. Short of
copying out that code at app launch and using it, you're likely to end
Yes, we jit the code, so we inline the currently used code: unless
the implementation changes during runtime (which I guess could be
possible,
but very unlikely:-) it should be safe.
up with a worse implementation for various systems than the current
code. And while copying out that code at app launch may seem
tempting,
even that is dangerous if the location of __pthread_getspecific
changes
in the future.
There is no dependency on the current location of __pthread_getspecific
(pthread_getspecific is disassembled to get its address, so
we don't depend on the name either).
Dump of assembler code for function __pthread_getspecific:
0xffff82c0 <__pthread_getspecific+0>: nop
0xffff82c4 <__pthread_getspecific+4>: .long 0x0
0xffff82c8 <__pthread_getspecific+8>: .long 0x0
0xffff82cc <__pthread_getspecific+12>: .long 0x0
[...]
I'm not sure how you got that output, but here's what I get when I
debug Safari on my PowerBook running 10.3.6:
[...]
0xffff82c0 in __pthread_getspecific ()
(gdb) x /6i $pc
0xffff82c0 <__pthread_getspecific>: rlwinm r5,r3,2,0,29
I used the disas command in gdb, which apparently uses another codepath
to resolve symbols and their location. Using x/i works for me, too, so
mistery solved (though you may want to check with the gdb people if
that
is the intended behaviour of disas).
Thanks.
lupus
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden