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

[Pedro Alves <palves at redhat dot com>]

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