This is the mail archive of the
mailing list for the GDB project.
Re: Debugging issue with gdbserver and a daemon on the target
- From: Pedro Alves <palves at redhat dot com>
- To: Laszlo Papp <lpapp at kde dot org>
- Cc: gdb at sourceware dot org
- Date: Tue, 19 Aug 2014 17:12:29 +0100
- Subject: Re: Debugging issue with gdbserver and a daemon on the target
- Authentication-results: sourceware.org; auth=none
- References: <CAOMwXhPxtfv7f=akjpuTh+HNCGDeEm0vxen1Kp3pPco++gvuLg at mail dot gmail dot com> <53F3743F dot 3000106 at redhat dot com> <CAOMwXhMmyXmHi9gZADtkTYb9mbF2hZRv2vHPC5AEcNWkE9duBg at mail dot gmail dot com>
On 08/19/2014 05:02 PM, Laszlo Papp wrote:
> On Tue, Aug 19, 2014 at 4:58 PM, Pedro Alves <email@example.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
>>> #2 0x0003284c in main (argc=0, argv=0x0) at src/bar.c:679
>>> ... 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
>>> 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".
>> 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.
> 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