CODEWITHSUNDEEP
variablesgdbpthreadsgdbserver
nass
nass

Reputation: 1495

gdb cannot access variables after spawning a thread

I am trying to debug an application, after migrating from an old development board to a new one (iMX6 sabre lite board with ARM cortex A9). I'm also running gdb on the host and gdbserver on the development board as explain in the __answer__section here how can i change the runtime libraries (libc ,ld, etc) used by gdb in cross (ARM) debugging

while trying to run the application and on executing the step to create a thread I get this:

(gdb) 
681             if (pthread_create(&serial_thread, &attr_detach, read_serial, argv[1]) != 0){
(gdb) 
    Cannot remove breakpoints because program is no longer writable.
    Further execution is probably impossible.
0x00023308 in main (
    argc=<error reading variable: Cannot access memory at address 0x7efffc8c>, 
    argv=<error reading variable: Cannot access memory at address 0x7efffc88>)
    at main_process/main_process.c:681
681             if (pthread_create(&serial_thread, &attr_detach, read_serial, argv[1]) != 0){
    warning: Error removing breakpoint 0
    Cannot access memory at address 0x7efffc88
(gdb) info threads
      Id   Target Id         Frame 
    * 1    Thread 2588.2588  0x00023308 in main (
    argc=<error reading variable: Cannot access memory at address 0x7efffc8c>, 
    argv=<error reading variable: Cannot access memory at address 0x7efffc88>)
    at main_process/main_process.c:681

I can not continue with the debug execution after that. if i simply run through the code (instead of stepping through it) I'll get

(gdb) c
Continuing.
[Inferior 1 (process 2601) exited with code 0377]

if I add a breakpoint in the thread that is to be created, I will get the execution to halt there, but continuing afterwards is impossible (it will not exit either).

I read about the posibility that the thread stack size may be small, but it is 8MB and I am only passing an argument argv[1] (which is empty at the moment) to the thread.

I used the Linaro gcc-linaro-arm-linux-gnueabi-2012.04-20120426_linux toolchain to create my application. and the shared libraries running on the board (and used while debugging) belong to LTIB_201204 rootfs.

Thank you for your help

Upvotes: 2

Views: 2739

Answers (1)

scottt
scottt

Reputation: 7248

Can you first check that libthread_db.so exists on the board and that it is unstripped (check nm output) ? I've never used LTIB personally but from page 2 this Freescale application note:

To correctly catch process events like loading a shared library or creation of a thread, the shared libraries that implement these common functionalities must be deployed on target un-stripped of symbols. For Linux userspace those are ld.so, libthread_db.so, libpthread.so, and for the particular case of i.MX/LTIB, to achieve that uncheck strip options on LTIB Target Image Generation menu.

Upvotes: 2

Related Questions