From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6499 invoked by alias); 19 Aug 2014 16:12:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 6487 invoked by uid 89); 19 Aug 2014 16:12:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 19 Aug 2014 16:12:40 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7JGCVfk029499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Aug 2014 12:12:32 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7JGCU9P018939; Tue, 19 Aug 2014 12:12:30 -0400 Message-ID: <53F3776D.2010705@redhat.com> Date: Tue, 19 Aug 2014 16:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Laszlo Papp CC: gdb@sourceware.org Subject: Re: Debugging issue with gdbserver and a daemon on the target References: <53F3743F.3000106@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-08/txt/msg00083.txt.bz2 On 08/19/2014 05:02 PM, Laszlo Papp wrote: > On Tue, Aug 19, 2014 at 4:58 PM, Pedro Alves 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 "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