From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25663 invoked by alias); 19 Aug 2014 16:02:13 -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 25654 invoked by uid 89); 19 Aug 2014 16:02:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pd0-f171.google.com Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 19 Aug 2014 16:02:11 +0000 Received: by mail-pd0-f171.google.com with SMTP id z10so9956179pdj.16 for ; Tue, 19 Aug 2014 09:02:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GH8diJGISuIAx4vM6U1JJ6DYJ2STL/Hr9qtJSMJp9JM=; b=a8n6vJ98Z871ODmJ4mhORo1Mq/mGHHeOekZr2Ms+CEunOubyJrIA+7jpV3ovvd2UvF 6EWfOIT30NO2jn6sZATQVokbVtaQekn1/7srHH4VwK3ZjjVjROQBZamOG3yAoomZBK7l sjPJ3STdXFos8DoY9vT1tseI11WvaaSbV+txeJ8cz2xZ5jzMT4wO0qPnNHmfG/hYWgzT 2GVM/V0l5WKjtBsDRrcvQchNywm2XZX6/I15QtrbMHUrn3lUqZGP0DO3zSJKN6OnvJKw TgOcH+AYpVeYPbHAXWxDu97oEWM+O4uHxyfDzhvJZ+biwGxFLBK+AGwwUD5UHli0P+z5 /zgg== X-Gm-Message-State: ALoCoQlODg2D6RzN7BQsRQOd6fTKhK0VZPN1v9MslnAuWod2Xbd2fZqQx65QLNc8NIjBCdlKgOJs MIME-Version: 1.0 X-Received: by 10.70.52.165 with SMTP id u5mr16221804pdo.62.1408464126362; Tue, 19 Aug 2014 09:02:06 -0700 (PDT) Received: by 10.70.57.136 with HTTP; Tue, 19 Aug 2014 09:02:06 -0700 (PDT) In-Reply-To: <53F3743F.3000106@redhat.com> References: <53F3743F.3000106@redhat.com> Date: Tue, 19 Aug 2014 16:02:00 -0000 Message-ID: Subject: Re: Debugging issue with gdbserver and a daemon on the target From: Laszlo Papp To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00081.txt.bz2 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? Btw: gdbserver --version GNU gdbserver (GDB) 7.5.1 arm-polatis-linux-gnueabi-gdb --version GNU gdb (GDB) 7.5.1