site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Not much we can do about this... Jim On Dec 21, 2004, at 12:04 PM, darwin-dev-request@lists.apple.com 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 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 lupus _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. On 12/20/04 Eric Albert wrote: 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. [...] 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. This email sent to site_archiver@lists.apple.com