|
From: Julian S. <js...@ac...> - 2006-12-14 00:02:42
|
On Wednesday 13 December 2006 09:26, Bart Van Assche wrote: > On 12/13/06, Tom Hughes <to...@co...> wrote: > > I think the problem is that pthread_spin_unlock is an alias for > > pthread_spin_init (ie they are the same routine) and valgrind sees > > the init routine first so attaches that name to the address: > > > > dellow [~] % objdump -T /lib64/libpthread.so.0 | grep > > pthread_spin_unlock 000000382700ab70 g DF .text 0000000000000009 > > GLIBC_2.2.5 pthread_spin_unlock > > > > dellow [~] % objdump -T /lib64/libpthread.so.0 | grep 000000382700ab70 > > 000000382700ab70 g DF .text 0000000000000009 GLIBC_2.2.5 > > pthread_spin_init 000000382700ab70 g DF .text 0000000000000009 > > GLIBC_2.2.5 pthread_spin_unlock > > > > I don't think valgrind's symbol table can cope with a many-one mapping > > from names to addresses, so we just remember the first name we see. > > > > Given that the main use of the symbol table is mapping the other way > > for backtraces, this makes some sense, as you can only show one name > > for an address in a backtrace. > > > > Tom > > This explanation sounds perfectly reasonable, but doesn't give me a > solution: does the above mean that it's impossible to implement a > wrapper for pthread_spin_unlock() in a Valgrind tool ? Well, you could write a wrapper for pthread_spin_init() instead? Or supply wrappers for both, factoring the real work into a routine shared by both wrappers. The latter sounds like a more robust approach. J |