* TLS on powerpc(32/64)
@ 2006-09-21 23:20 Prosun Niyogi
2006-09-21 23:52 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: Prosun Niyogi @ 2006-09-21 23:20 UTC (permalink / raw)
To: gdb; +Cc: pniyogi
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
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.
Here's a paste:
shadows:~/pniyogi # ldd ./tls
linux-vdso64.so.1 => (0x0000000000100000)
libpthread.so.0 => /lib64/libpthread.so.0
libgcc_s.so.1 => /lib64/libgcc_s.so.1
libc.so.6 => /lib64/libc.so.6
/lib64/ld64.so.1 (0x0000040000000000)
shadows:~/pniyogi # ./gdb-new ./tls
GNU gdb 6.5.50.20060811-cvs
***********
(gdb) b 80
Breakpoint 1 at 0x10000d6c: file tls.c, line 80.
(gdb) r
Starting program: /root/pniyogi/tls
[New LWP 8210]
[Switching to LWP 8210]
Breakpoint 1, spin (vp=0x0) at tls.c:80
80 thread_local_val[ me ] = a_thread_local;
(gdb) p a_thread_local
Cannot find thread-local variables on this target
(gdb)
Also attaching a testcase tls.c that I was compiling
with -m64 -g
Any assistance/insight would be appreciated.
-Prosun Niyogi
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 42213221-tls.c --]
[-- Type: text/x-csrc; name="tls.c", Size: 4861 bytes --]
/* BeginSourceFile tls.c
This file creates and deletes threads. It uses thread local storage
variables too. */
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <pthread.h>
#include <semaphore.h>
#include <errno.h>
#define N_THREADS 3
/* Uncomment to turn on debugging output */
/*#define START_DEBUG*/
/* Thread-local storage. */
__thread int a_thread_local;
__thread int another_thread_local;
/* Global variable just for info addr in gdb. */
int a_global;
/* Print the results of thread-local storage. */
int thread_local_val[ N_THREADS ];
int another_thread_local_val[ N_THREADS ];
/* Semaphores to make sure the threads are alive when we print the TLS
variables from gdb. */
sem_t tell_main, tell_thread;
void print_error ()
{
switch (errno)
{
case EAGAIN:
fprintf (stderr, "EAGAIN\n");
break;
case EINTR:
fprintf (stderr, "EINTR\n");
break;
case EINVAL:
fprintf (stderr, "EINVAL\n");
break;
case ENOSYS:
fprintf (stderr, "ENOSYS\n");
break;
case ENOENT:
fprintf (stderr, "ENOENT\n");
break;
case EDEADLK:
fprintf (stderr, "EDEADLK\n");
break;
default:
fprintf (stderr, "Unknown error\n");
break;
}
}
/* Routine for each thread to run, does nothing. */
void *spin( vp )
void * vp;
{
int me = (long) vp;
int i;
/* Use a_global. */
a_global++;
a_thread_local = 0;
another_thread_local = me;
for( i = 0; i <= me; i++ ) {
a_thread_local += i;
printf("Thread local = %d\n", a_thread_local);
}
another_thread_local_val[me] = another_thread_local;
thread_local_val[ me ] = a_thread_local; /* here we know tls value */
if (sem_post (&tell_main) == -1)
{
fprintf (stderr, "th %d post on sem tell_main failed\n", me);
print_error ();
return;
}
#ifdef START_DEBUG
fprintf (stderr, "th %d post on tell main\n", me);
#endif
while (1)
{
#ifdef START_DEBUG
fprintf (stderr, "th %d start wait on tell_thread\n", me);
#endif
if (sem_wait (&tell_thread) == 0)
break;
if (errno == EINTR)
{
#ifdef START_DEBUG
fprintf (stderr, "th %d wait tell_thread got EINTR, rewaiting\n", me);
#endif
continue;
}
else
{
fprintf (stderr, "th %d wait on sem tell_thread failed\n", me);
print_error ();
return;
}
}
#ifdef START_DEBUG
fprintf (stderr, "th %d Wait on tell_thread\n", me);
#endif
}
void
do_pass()
{
int i;
pthread_t t[ N_THREADS ];
int err;
for( i = 0; i < N_THREADS; i++)
{
thread_local_val[i] = 0;
another_thread_local_val[i] = 0;
}
if (sem_init (&tell_main, 0, 0) == -1)
{
fprintf (stderr, "tell_main semaphore init failed\n");
return;
}
if (sem_init (&tell_thread, 0, 0) == -1)
{
fprintf (stderr, "tell_thread semaphore init failed\n");
return;
}
/* Start N_THREADS threads, then join them so that they are terminated. */
for( i = 0; i < N_THREADS; i++ )
{
err = pthread_create( &t[i], NULL, spin, (void *) (long) i );
if( err != 0 ) {
fprintf(stderr, "Error in thread %d create\n", i );
}
}
for( i = 0; i < N_THREADS; i++ )
{
while (1)
{
#ifdef START_DEBUG
fprintf (stderr, "main %d start wait on tell_main\n", i);
#endif
if (sem_wait (&tell_main) == 0)
break;
if (errno == EINTR)
{
#ifdef START_DEBUG
fprintf (stderr, "main %d wait tell_main got EINTR, rewaiting\n", i);
#endif
continue;
}
else
{
fprintf (stderr, "main %d wait on sem tell_main failed\n", i);
print_error ();
return;
}
}
}
#ifdef START_DEBUG
fprintf (stderr, "main done waiting on tell_main\n");
#endif
i = 10; /* Here all threads should be still alive. */
for( i = 0; i < N_THREADS; i++ )
{
if (sem_post (&tell_thread) == -1)
{
fprintf (stderr, "main %d post on sem tell_thread failed\n", i);
print_error ();
return;
}
#ifdef START_DEBUG
fprintf (stderr, "main %d post on tell_thread\n", i);
#endif
}
for( i = 0; i < N_THREADS; i++ )
{
err = pthread_join(t[i], NULL );
if( err != 0 )
{
fprintf (stderr, "error in thread %d join\n", i );
}
}
i = 10; /* Null line for setting bpts on. */
}
int
main()
{
do_pass ();
return 0; /* Set breakpoint here before exit. */
}
/* EndSourceFile */
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: TLS on powerpc(32/64)
2006-09-21 23:20 TLS on powerpc(32/64) Prosun Niyogi
@ 2006-09-21 23:52 ` Daniel Jacobowitz
2006-09-22 13:53 ` Prosun Niyogi
[not found] ` <20060922025718.19237.qmail@web38906.mail.mud.yahoo.com>
0 siblings, 2 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2006-09-21 23:52 UTC (permalink / raw)
To: Prosun Niyogi; +Cc: gdb, pniyogi
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: TLS on powerpc(32/64)
2006-09-21 23:52 ` Daniel Jacobowitz
@ 2006-09-22 13:53 ` Prosun Niyogi
2006-09-22 18:03 ` Michael Snyder
[not found] ` <20060922025718.19237.qmail@web38906.mail.mud.yahoo.com>
1 sibling, 1 reply; 8+ messages in thread
From: Prosun Niyogi @ 2006-09-22 13:53 UTC (permalink / raw)
To: gdb; +Cc: pniyogi
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 <drow@false.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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: TLS on powerpc(32/64)
2006-09-22 13:53 ` Prosun Niyogi
@ 2006-09-22 18:03 ` Michael Snyder
2006-09-22 18:18 ` Prosun Niyogi
0 siblings, 1 reply; 8+ messages in thread
From: Michael Snyder @ 2006-09-22 18:03 UTC (permalink / raw)
To: Prosun Niyogi; +Cc: gdb, pniyogi
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 <drow@false.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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: TLS on powerpc(32/64)
2006-09-22 18:03 ` Michael Snyder
@ 2006-09-22 18:18 ` Prosun Niyogi
2006-09-22 18:43 ` Michael Snyder
0 siblings, 1 reply; 8+ messages in thread
From: Prosun Niyogi @ 2006-09-22 18:18 UTC (permalink / raw)
To: Michael Snyder; +Cc: gdb, pniyogi
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: TLS on powerpc(32/64)
2006-09-22 18:18 ` Prosun Niyogi
@ 2006-09-22 18:43 ` Michael Snyder
2006-09-22 19:01 ` Prosun Niyogi
0 siblings, 1 reply; 8+ messages in thread
From: Michael Snyder @ 2006-09-22 18:43 UTC (permalink / raw)
To: Prosun Niyogi; +Cc: gdb, pniyogi
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: TLS on powerpc(32/64)
2006-09-22 18:43 ` Michael Snyder
@ 2006-09-22 19:01 ` Prosun Niyogi
0 siblings, 0 replies; 8+ messages in thread
From: Prosun Niyogi @ 2006-09-22 19:01 UTC (permalink / raw)
To: Michael Snyder; +Cc: gdb, pniyogi
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.Snyder@palmsource.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
^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <20060922025718.19237.qmail@web38906.mail.mud.yahoo.com>]
end of thread, other threads:[~2006-09-22 19:01 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-21 23:20 TLS on powerpc(32/64) Prosun Niyogi
2006-09-21 23:52 ` Daniel Jacobowitz
2006-09-22 13:53 ` Prosun Niyogi
2006-09-22 18:03 ` Michael Snyder
2006-09-22 18:18 ` Prosun Niyogi
2006-09-22 18:43 ` Michael Snyder
2006-09-22 19:01 ` Prosun Niyogi
[not found] ` <20060922025718.19237.qmail@web38906.mail.mud.yahoo.com>
2006-09-22 14:03 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox