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

Pedro Alves
2014-08-19T16:12:42Z

On 08/19/2014 05:02 PM, Laszlo Papp wrote:
> On Tue, Aug 19, 2014 at 4:58 PM, Pedro Alves <palves@redhat.com> 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