TLS on powerpc(32/64)

TLS on powerpc(32/64)

[Prosun Niyogi]

[-- 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 */

Re: TLS on powerpc(32/64)

[Daniel Jacobowitz]

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

Re: TLS on powerpc(32/64)

[Prosun Niyogi]

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 

Re: TLS on powerpc(32/64)

[Daniel Jacobowitz]

On Thu, Sep 21, 2006 at 07:57:18PM -0700, Prosun Niyogi wrote:
>   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.

Look at where the error message you're getting comes from.  How did
we get there?  Why do the predicate functions higher up in that
function return false?

-- 
Daniel Jacobowitz
CodeSourcery

Re: TLS on powerpc(32/64)

[Michael Snyder]

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 

Re: TLS on powerpc(32/64)

[Prosun Niyogi]

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 

Re: TLS on powerpc(32/64)

[Michael Snyder]

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?

Re: TLS on powerpc(32/64)

[Prosun Niyogi]

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