Re: Problems debugging multithreaded application remotely

[Ulf Magnusson <ulfalizer at gmail dot com>]

I had accidentally used versions of libthread_db.so.1 compiled with
different different options on the two systems. Once I got that fixed,
thread debugging started working correctly.

/Ulf

On Thu, Apr 1, 2010 at 12:59 PM, Ulf Magnusson <ulfalizer@gmail.com> wrote:
> Hi,
>
> I'm trying to set up remote debugging of a multithreaded application running on
> my BeagleBoard (ARM-based system). I've compiled an arm-linux-gdb and a
> gdbserver using Buildroot (a toolchain and root filesystem generation package
> that uses uClibc). On the target (BeagleBoard), I run:
>
> # gdbserver /dev/ttyS2 myapp
> Process myapp created; pid = 644
> Remote debugging using /dev/ttyS2
>
> On my host system (x86-64) I run:
>
> $ arm-linux-gdb -b 115200 myapp
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. ?Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=x86_64-pc-linux-gnu
> --target=arm-linux-uclibcgnueabi"...
>
> I issue the commands:
>
> (gdb) set sysroot /home/ulf/devel/broot/arm/buildroot-2010.02/output/target
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> [New Thread 648]
> 0x000080d0 in _start ()
>
> The sysroot directory is a directory within buildroot that corresponds to the
> root filesystem being built. It contains the same libraries, in the same
> relative locations, as on the target system, e.g.
>
> $ ls /home/ulf/devel/broot/arm/buildroot-2010.02/output/target/lib
> ld-uClibc-0.9.30.2.so ?libgcc_s.so.1 ? ? ? ? ? libresolv.so.0
> ld-uClibc.so.0 ? ? ? ? libm-0.9.30.2.so ? ? ? ?librt-0.9.30.2.so
> libcrypt-0.9.30.2.so ? libm.so.0 ? ? ? ? ? ? ? librt.so.0
> libcrypt.so.0 ? ? ? ? ?libnsl-0.9.30.2.so ? ? ?libthread_db-0.9.30.2.so
> libc.so.0 ? ? ? ? ? ? ?libnsl.so.0 ? ? ? ? ? ? libthread_db.so.1
> libdl-0.9.30.2.so ? ? ?libpthread-0.9.30.2.so ?libuClibc-0.9.30.2.so
> libdl.so.0 ? ? ? ? ? ? libpthread.so.0 ? ? ? ? libutil-0.9.30.2.so
> libgcc_s.so ? ? ? ? ? ?libresolv-0.9.30.2.so ? libutil.so.0
>
> Breaking on e.g. 'main' works fine, but if I tell gdb to continue running the
> program, I get:
>
> (gdb) c
> Continuing.
>
> Program received signal SIG32, Real-time event 32.
> 0x00e40ff8 in sigsuspend ()
>
> After this GDB seems confused, and never breaks on breakpoints I know are
> visited, even if I do 'handle SIG32 nostop noprint pass'. I'm guessing the
> signal is due to the way the threads implementation works, and that GDB isn't
> interpreting it as it should. What could be wrong?
>
>
> Some additional info:
> * uClibc is compiled with PTHREADS_DEBUG_SUPPORT.
> * linuxthreads is used instead of NPTL (LINUXTHREADS_OLD=y in uClibc config)
> * BR2_ENABLE_DEBUG (build packages with debugging symbols) is enabled in
> ?Buildroot.
> * The program is compiled with:
>
> arm-linux-gcc \
> ?-static \
> ?-g \
> ?-march=armv7-a -mtune=cortex-a8 -mfpu=neon \
> ?-ftree-vectorize -mfloat-abi=softfp \
> ?-D_REENTRANT \
> ?-I"$sdkdir_arm"/platforms/linuxsdk/include \
> ?-I"$dfbdir_arm"/output/staging/usr/include/directfb \
> ?myapp.c \
> ?$dfbdir_arm/output/staging/usr/lib/directfb-1.4-0/systems/libdirectfb_fbdev.o
> \
> ?$dfbdir_arm/output/staging/usr/lib/directfb-1.4-0/wm/libdirectfbwm_default.o \
> ?$dfbdir_arm/output/staging/usr/lib/directfb-1.4-0/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_png.o
> \
> ?$dfbdir_arm/output/staging/usr/lib/directfb-1.4-0/inputdrivers/libdirectfb_linux_input.o
> \
> ?-L"$dfbdir_arm"/output/target/usr/lib \
> ?-L"$sdkdir_arm"/platforms/linuxsdk/lib \
> ?-ldirectfb -lfusion -ldirect -lpthread -lz -lpng -lmyapplib -ldl -lm \
> ?-o arm/myapp
>
> where arm-linux-gcc is part of the ARM toolchain built with Buildroot.
>
> Thanks,
> Ulf
>