TLS on powerpc(32/64)

Array

How can I tell whether GDB is loading libthread_db?
"info threads" works... I would think libthread_db
must be loaded for that to work.
 
Also, in gdb(linux-thread_db.c) -
 
 __/* glibc doesn't provide the needed interface.  */
 if (!td_thr_tls_get_addr_p)
   throw_error (TLS_NO_LIBRARY_SUPPORT_ERROR,
                _("No TLS library support"));
 __/* Caller should have verified that lm != 0.  */
 gdb_assert (lm != 0);
 __/* Get info about the thread.  */
 thread_info = find_thread_pid (ptid);
 thread_db_map_id2thr (thread_info, 1);
 __/* Finally, get the address of the variable.  */
 err = td_thr_tls_get_addr_p
(&thread_info->private->th, (void *) lm,
                              offset, &address);
So the glibc interface is found... does that not mean
that libthread_db is loaded and found by GDB?
 
Apologies for the ignorance, just looking for how I
can check to see why td_thr_tls_get_addr_p() doesnt
return an appropriate value.
 
So judging from the tone of your comment, I should
expect to be able to print the value of a __thread
variable on ppc64, and there arent any known issues
preventing me from doing so? I have tried on SLES, FC,
and now cvs-head, and all three have failed.
 
Can you suggest where I should look next? I took a
quick look at libthread_db in glibc, and it looks like
none of the fuctions have changed in libc. 
 
Thanks,
 
Prosun Niyogi

--- Daniel Jacobowitz <drowfalse.org> wrote:

> On Thu, Sep 21, 2006 at 04:20:47PM -0700, Prosun
> Niyogi wrote:
> > Hi, 
> > I've been struggling the last few days on getting
> gdb
> > to work correctly on a powerpc64 machine. Built as
> > ppc-64-linux, debugging ppc64 binaries linked
> against
> > libpthread. It seems to me that gdb's TLS access
> does
> > not work correctly on these platforms. Attempting
> to
> > print a variable of type __thread doesnt work. 
> 
> It looks to me like GDB has failed to load
> libthread_db for some
> reason.  I don't know why not; you'll have to look
> into it.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 

On Fri, 2006-09-22 at 06:53 -0700, Prosun Niyogi wrote:
> How can I tell whether GDB is loading libthread_db?
> "info threads" works... I would think
libthread_db
> must be loaded for that to work.

If it's a native linux (or solaris) gdb, yes.

You could also try running gdb under gdb -- with verbose 
mode turned on in the "outer" or master gdb.  Then
the outer
gdb would notify you whenever the inner gdb loaded a shared
library, and you could look for libthread_db.

> Also, in gdb(linux-thread_db.c) -
>  
>  __/* glibc doesn't provide the needed interface.  */
>  if (!td_thr_tls_get_addr_p)
>    throw_error (TLS_NO_LIBRARY_SUPPORT_ERROR,
>                 _("No TLS library support"));
>  __/* Caller should have verified that lm != 0.  */
>  gdb_assert (lm != 0);
>  __/* Get info about the thread.  */
>  thread_info = find_thread_pid (ptid);
>  thread_db_map_id2thr (thread_info, 1);
>  __/* Finally, get the address of the variable.  */
>  err = td_thr_tls_get_addr_p
> (&thread_info->private->th, (void *) lm,
>                               offset, &address);
> So the glibc interface is found... does that not mean
> that libthread_db is loaded and found by GDB?

libthread_db is a separate shared library, and might be
missing or something.  But that would be unusual, I suppose.

> Apologies for the ignorance, just looking for how I
> can check to see why td_thr_tls_get_addr_p() doesnt
> return an appropriate value.

Version problem?  There were versions of glibc and
libthread_db
that predated TLS.


> So judging from the tone of your comment, I should
> expect to be able to print the value of a __thread
> variable on ppc64, and there arent any known issues
> preventing me from doing so? I have tried on SLES, FC,
> and now cvs-head, and all three have failed.

Can you do a "ptype" or "whatis" on the
type?

 
> Can you suggest where I should look next? I took a
> quick look at libthread_db in glibc, and it looks like
> none of the fuctions have changed in libc. 
>  
> Thanks,
>  
> Prosun Niyogi
> 
> --- Daniel Jacobowitz <drowfalse.org> wrote:
> 
> > On Thu, Sep 21, 2006 at 04:20:47PM -0700, Prosun
> > Niyogi wrote:
> > > Hi, 
> > > I've been struggling the last few days on
getting
> > gdb
> > > to work correctly on a powerpc64 machine.
Built as
> > > ppc-64-linux, debugging ppc64 binaries linked
> > against
> > > libpthread. It seems to me that gdb's TLS
access
> > does
> > > not work correctly on these platforms.
Attempting
> > to
> > > print a variable of type __thread doesnt
work. 
> > 
> > It looks to me like GDB has failed to load
> > libthread_db for some
> > reason.  I don't know why not; you'll have to look
> > into it.
> > 
> > -- 
> > Daniel Jacobowitz
> > CodeSourcery
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
protection around 
> http://mail.yahoo.com 

Hi, thanks for your response. No, it isnt a
glibc/libthread_db version problem ... I've built the
same sources for ia32 and the test passes fine. It on
powerpc that I see the failure. 

So, after a little digging, it seems like the load
module address that gdb is using to make the call to
td_thr_tls_get_addr_p is bogus. At the moment, I am
comparing results with gdb-6.3 which works in my
envrionment. The offset to the variable within LM
looks fine. Still debugging. I am not too sure of what
the concept of the load module address is. Where would
be the appropriate place to look for background info?
glibc TLS documentation?

The lm_addr calculated in dwarf2loc.c looks bad on
ppc. 

-Prosun

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 

On Fri, 2006-09-22 at 11:18 -0700, Prosun Niyogi wrote:
> Hi, thanks for your response. No, it isnt a
> glibc/libthread_db version problem ... I've built the
> same sources for ia32 and the test passes fine. It on
> powerpc that I see the failure. 
> 
> So, after a little digging, it seems like the load
> module address that gdb is using to make the call to
> td_thr_tls_get_addr_p is bogus. At the moment, I am
> comparing results with gdb-6.3 which works in my
> envrionment. The offset to the variable within LM
> looks fine. Still debugging. I am not too sure of what
> the concept of the load module address is. Where would
> be the appropriate place to look for background info?
> glibc TLS documentation?
> 
> The lm_addr calculated in dwarf2loc.c looks bad on
> ppc. 

That's a little beyond my knowledge.  Could it be a 32/64
wordsize issue?  A sign extension issue?

Apologies, I incorrectly reported that the lm address
was wrong. Actually, both lm and addr (as reported by
td_thr_tls_get_addr_p) are the same.. ie,
tg_thr_tls_get_addr_p returns the address of lm,
rather than the address of the variable.

--Prosun Niyogi  

--- Michael Snyder <Michael.Snyderpalmsource.com>
wrote:

> On Fri, 2006-09-22 at 11:18 -0700, Prosun Niyogi
> wrote:
> > Hi, thanks for your response. No, it isnt a
> > glibc/libthread_db version problem ... I've built
> the
> > same sources for ia32 and the test passes fine. It
> on
> > powerpc that I see the failure. 
> > 
> > So, after a little digging, it seems like the load
> > module address that gdb is using to make the call
> to
> > td_thr_tls_get_addr_p is bogus. At the moment, I
> am
> > comparing results with gdb-6.3 which works in my
> > envrionment. The offset to the variable within LM
> > looks fine. Still debugging. I am not too sure of
> what
> > the concept of the load module address is. Where
> would
> > be the appropriate place to look for background
> info?
> > glibc TLS documentation?
> > 
> > The lm_addr calculated in dwarf2loc.c looks bad on
> > ppc. 
> 
> That's a little beyond my knowledge.  Could it be a
> 32/64
> wordsize issue?  A sign extension issue?
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com