[Buildroot] Can't debug threaded app on ARM920 (SIG32)

[Buildroot] Can't debug threaded app on ARM920 (SIG32)

[Grant Edwards]

I'm trying to debug a threaded application using gdbserver on
an ARM920T platform (Atmel AT91RM9200 eval board), and I'm not
having much luck.  Whenver a new thread is started, I see a
SIG32:

Here's a typical session:

   GNU gdb 6.8
   [...]
   This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux-uclibc".
   [New Thread 797]
   0x40000930 in _start ()
      from /home/grante/processors/atmel/RM9200/buildroot-2009.05/project_build_arm/uclibc/root/lib/ld-uClibc.so.0
   (gdb) break 62
   Breakpoint 1 at 0x8dc8: file hello.c, line 62.
   (gdb) c
   Continuing.
   
   Breakpoint 1, main () at hello.c:62
   62            s = pthread_create(tid+i, attrp, thread, (void*)i);  abort_if_error(s);
   (gdb) next
   
   Program received signal SIG32, Real-time event 32.
   0x400445d4 in ?? ()
   (gdb) info thread
   [New Thread 798]
   [New Thread 799]
     3 Thread 799  0x40065700 in ?? ()
     2 Thread 798  0x40043918 in ?? ()
   * 1 Thread 797  0x400445d4 in ?? ()
   warning: Couldn't restore frame in current thread, at frame 0
   0x400445d4 in ?? ()

I've tried both NPTL and Linuxthreads, both act the same.

I've verifed using strace that target gdbserver is finding
libthread_db.so and that the dev-host gdb is finding the
target-arch .so files. I've verified that the target-arch
libpthread .so files aren't stripped.

Here are config items contains the string "thread" in my
.config files (using NPTL):

   $ find . -name .config | xargs grep -i thread
   ./toolchain_build_arm/uClibc-0.9.30.1/.config:# HAS_NO_THREADS is not set
   ./toolchain_build_arm/uClibc-0.9.30.1/.config:UCLIBC_HAS_THREADS=y
   ./toolchain_build_arm/uClibc-0.9.30.1/.config:PTHREADS_DEBUG_SUPPORT=y
   ./toolchain_build_arm/uClibc-0.9.30.1/.config:LINUXTHREADS_OLD=y
   ./.config:BR2_PTHREAD_DEBUG=y
   ./.config:# BR2_PTHREADS_NONE is not set
   ./.config:# BR2_PTHREADS is not set
   ./.config:# BR2_PTHREADS_OLD is not set
   ./.config:BR2_PTHREADS_NATIVE=y

I've spent hours reading mailing-list postings and can't find
_any_ real information on how multi-threaded debugging is
supposed to work or what causes the SIG32.  All I found is
people complaining about it as early as 2002 and as recently as
a couple weeks ago.  Some of them eventually get it to work,
some don't.

So far, I haven't even been able to narrow down which gdb
(server or client) is broken.  I've posted questions to the gdb
mailing list, and haven't gotten any response there.

[I've also tried the same exercise on a PPC platform (using
LTIB/glibc instead of buildroot), and those results were even
worse: gdb seemed to be completely unaware of threads.]

Can somebody point me to _any_ hard information on how to get
thread debugging working using gdbserver?

-- 
Grant Edwards                   grante             Yow! Do you have exactly
                                  at               what I want in a plaid
                               visi.com            poindexter bar bat??

[Buildroot] Can't debug threaded app on ARM920 (SIG32)

[Grant Edwards]

On 2009-06-22, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> I'm trying to debug a threaded application using gdbserver on
> an ARM920T platform (Atmel AT91RM9200 eval board), and I'm not
> having much luck.  Whenver a new thread is started, I see a
> SIG32:

Gdb 6.8 is broken for ARM targets.  6.7.1 works fine.

-- 
Grant Edwards                   grante             Yow! Did YOU find a
                                  at               DIGITAL WATCH in YOUR box
                               visi.com            of VELVEETA?

[Buildroot] Can't debug threaded app on ARM920 (SIG32)

[Thomas Petazzoni]

Le Tue, 23 Jun 2009 18:19:14 +0000 (UTC),
Grant Edwards <grant.b.edwards@gmail.com> a ?crit :

> > I'm trying to debug a threaded application using gdbserver on
> > an ARM920T platform (Atmel AT91RM9200 eval board), and I'm not
> > having much luck.  Whenver a new thread is started, I see a
> > SIG32:
> 
> Gdb 6.8 is broken for ARM targets.  6.7.1 works fine.

I was also having an issue with gdb 6.8 on ARM targets, with an error
message saying ?register no longer active?. It is fixed by
http://cvs.fedoraproject.org/viewvc/devel/gdb/gdb-6.8-bz436037-reg-no-longer-active.patch?revision=1.1

Not sure it is your problem, though.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Can't debug threaded app on ARM920 (SIG32)

[Grant Edwards]

On 2009-06-23, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Le Tue, 23 Jun 2009 18:19:14 +0000 (UTC),
> Grant Edwards <grant.b.edwards@gmail.com> a ??crit :
>
>> > I'm trying to debug a threaded application using gdbserver on
>> > an ARM920T platform (Atmel AT91RM9200 eval board), and I'm not
>> > having much luck.  Whenver a new thread is started, I see a
>> > SIG32:
>> 
>> Gdb 6.8 is broken for ARM targets.  6.7.1 works fine.
>
> I was also having an issue with gdb 6.8 on ARM targets, with an error
> message saying ??register no longer active??. It is fixed by
> http://cvs.fedoraproject.org/viewvc/devel/gdb/gdb-6.8-bz436037-reg-no-longer-active.patch?revision=1.1
>
> Not sure it is your problem, though.

I don't think it is.  It sounds like sticking with 6.7.1 for a
while is advisable.

-- 
Grant Edwards                   grante             Yow! FUN is never having to
                                  at               say you're SUSHI!!
                               visi.com            

[Buildroot] Can't debug threaded app on ARM920 (SIG32)

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> I was also having an issue with gdb 6.8 on ARM targets, with an error
 Thomas> message saying ?register no longer active?. It is fixed by
 Thomas> http://cvs.fedoraproject.org/viewvc/devel/gdb/gdb-6.8-bz436037-reg-no-longer-active.patch?revision=1.1

That sounds like something we would want to have in buildroot - Care
to make a patch?

-- 
Bye, Peter Korsgaard