Error at lookup Thread-Local Storage variable.

Hi,

I debug an application with a symbolic library in the same
directory as the binary.

Its linked like
$(CC)  -g solib_symbol.o -L. -lmd -lpthread -Wl,-rpath=./ -o
main

GDB is able to debug it correctly. The shared library is
found:
(gdb) info sharedlibrary
>From        To          Syms Read   Shared Object
Library
0xb7ffe510  0xb7ffe63c  Yes         ./libmd.so
...

Now there is a Thread-Local Storage variable (I call it
libkeks) in this shared library. 

(gdb) p libkeks
keks Cannot find shared library
`/home/deuling/md/solib/libmd.so' in dynamic linker's load
module list

target_translate_tls_address() fails to find the address for
it. I tracked it down to 
svr4_fetch_objfile_link_map() from solib-svr4.c. There is a
string compare between
objfile->name and a buffer. The problem is, that the
objfile contains the full-qualified
path to the library, but the buffer (like 'info
sharedlibrary': ./libmd.so) does not.
(objfile->name = /home/deuling/md/solib/libmd.so).

Is this a bug? Why is that objfile->name fully qualified
and the shared library isn't?
What would be the appropriate way to fix that? Qualify
./path to ./full/path and recompare the strings ?

Thanks in advance.


-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deulingde.ibm.com

On Wed, May 09, 2007 at 08:46:26PM +0200, Markus Deuling
wrote:
> target_translate_tls_address() fails to find the
address for it. I tracked it 
> down to svr4_fetch_objfile_link_map() from
solib-svr4.c. There is a string 
> compare between
> objfile->name and a buffer. The problem is, that the
objfile contains the 
> full-qualified
> path to the library, but the buffer (like 'info
sharedlibrary': ./libmd.so) 
> does not.
> (objfile->name = /home/deuling/md/solib/libmd.so).
> 
> Is this a bug? Why is that objfile->name fully
qualified and the shared library 
> isn't?

The name from the link map comes from ld.so; the name from
the objfile
has been through GDB.  ld.so doesn't always qualify names,
esp. in the
case of rpath.

> What would be the appropriate way to fix that? Qualify
./path to ./full/path 
> and recompare the strings ?

Figure out why GDB didn't save the original name anywhere? 
It looks
to me like you should walk the solib list (struct so_list)
to find the
entry that matches objfile.  Then you'll have
so_original_name to
compare with.

-- 
Daniel Jacobowitz
CodeSourcery