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

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? Btw:

gdbserver --version
GNU gdbserver (GDB) 7.5.1

arm-polatis-linux-gnueabi-gdb --version
GNU gdb (GDB) 7.5.1