Re: Debugging issue with gdbserver and a daemon on the target

On 08/19/2014 05:02 PM, Laszlo Papp wrote:
> On Tue, Aug 19, 2014 at 4:58 PM, Pedro Alves <[email protected]> wrote:
>> On 08/19/2014 04:44 PM, Laszlo Papp wrote:
>>
>>>
>>> gdbserver --attach 192.168.0.32:2345 pid-of-my-daemon
>>>
>>
>>> (gdb) bt
>>> #0  0x44ad26ec in select () at ../sysdeps/unix/syscall-template.S:81
>>> #1  0x0002ac08 in bar (timeout=10, name=0x42f30 <yy_ec+56> "foo") at
>>> src/socket.c:906
>>> #2  0x0003284c in main (argc=0, argv=0x0) at src/bar.c:679
>>> (gdb)
>>>
>>>
>>> ... And then I do some communication with the daemon where the foo
>>> function is executed based on the logs, but the breakpoint is not hit.
>>> I wished to try hardware breakpoints, but they are not presented on my
>>> hardware.
>>>
>>> Furthermore, if I use the same workflow on a binary that is
>>> "one-shot", i.e. not running continuously as a daemon, the debugging
>>> workflow for stopping at main works with exactly the aforementioned
>>> software breakpoint issue.
>>>
>>> I am completely clueless at this point. Do you know how I can debug a
>>> daemon with gdbserver?
>>
>> "daemon" and "select" makes me think "fork".  If the daemon is handling
>> requests by forking a child, and then it's the child that calls 'foo',
>> then this is expected, as GDBserver doesn't know how to follow forks
>> currently.  It's WIP, patches have been posted.  Meanwhile, the usual
>> thing to do it to attach to the child process the daemon spawns instead
>> of the main daemon pid.  You'll usually do that by adding a busyloop in
>> the child somewhere, like:
>>
>> volatile int gdb_here;
>>
>> while (!gdb_here)
>>   sleep (1);
>>
>> and after attaching to the child, do "print gdb_here = 1; continue".
>>
>> Thanks,
>> Pedro Alves
> 
> Thanks Pedro for the prompt reply. Unfortunately, I am already
> attaching to the child right after the fork. I wonder if this can
> happen if some source file was missing?

It shouldn't.  Source files are only used for display.  Where to
place a breakpoint is derived from the debug info in the binary.

I'd suggest just trying to step through the code instead of
putting a break at "foo", and see if that much works.  On an
arm system, stepping is actually implemented with magic
breakpoints behind the scenes.

> Btw:
> 
> gdbserver --version
> GNU gdbserver (GDB) 7.5.1
> 
> arm-polatis-linux-gnueabi-gdb --version
> GNU gdb (GDB) 7.5.1
> 

Knee-jerk reaction is to suggest a more recent GDB/GDBserver.  Note
building these isn't very hard.  There aren't that many
dependencies.

Thanks,
Pedro Alves