This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Problems debugging multithreaded application remotely


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]