Linux Remote Debugging Thread Error (GDBServer)

Question

I have an ARM device and I want to debug it. My host computer is Linux 12.04 and I am using Eclipse. GDBServer run on my target device.

I can debug single process application. But When I want to debug multithread application which contains pthread objects, debugging is fail. I run step by step but when I came to

pthread_create(&timerSettings.timerThread, NULL, &timerThread, NULL);

line debugger gives below error No source available for "0x40174c84".

So what should I do?

Any suggestion?

Thanks.

Answer 1

By running step by step your in effect asking the debugger to step into the phread_create() function, and of course you don't have the source code for that. If as I suspect you were anticipating that the debugger would take you to the source of your thread, well, I've some bad news; it doesn't work that way.

If you step over the pthread_create() that will create your thread which should show up in the task list in Eclipse if you're in the Debugger perspective. You can select your thread from there. If you do that the source code view will jump to wherever that thread has got to (more bad news coming). Remember that all this needs relatively modern versions of gdb (6 and upwards as I recall).

Now your problems really start. Debugging with threads in gdb isn't very good. When you select your thread you may find that no source code is displayed. This is because although you've stepped over the pthread_create() this does not mean that the thread has progressed as far as your first line of source code. This is because when gdb suspends a program every thread in that program is suspended, and the new thread probably hasn't got out of the standard library's thread initial code. So you have to set a breakpoint on the first line of source code in your thread and allow the program to free run until that breakpoint is hit.

But wait - in the meantime your main thread has waltzed off into the distance and you've lost control of that. You can't set a breakpoint on that because your program will be suspended by gdb whenever any breakpoint is hit.

In short its a right pain in the arsenal.

You can type gdb commands into Eclipse. This helps a little bit because you can then do things like set thread specific breakpoints, and set gdb in to non-stop mode and background async mode. These are better than nothing, but in my experience don't do the whole job. Worse still is that Eclipse seems utterly unaware of them (I may be out of date) so you're reduced to typing in the commands by hand. In which case you might as well not run inside Eclipse in the first place.

I suggest you take a look at this. A good trick is to put a sleep in a loop at the beginning of all your threads with the loop condition being some variable that never changes. That way when the thread is created you can switch to it, setup whatever breakpoints you want then change the loop variable's value yourself so that when you continue the thread it exits the loop and runs to your breakpoints.

--EDIT--

Seems I'm out of date. Take a look at this. Looks like Eclipse now is aware of non-stop mode, and thread specific breakpoints. Those coupled a catch-at-start sleep loop in every thread (perhaps Eclipse can solve that too now) will make it tolerable to debug threads.