From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5265 invoked by alias); 20 Aug 2014 08:36:28 -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 5253 invoked by uid 89); 20 Aug 2014 08:36:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pd0-f170.google.com Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 20 Aug 2014 08:36:26 +0000 Received: by mail-pd0-f170.google.com with SMTP id g10so11103577pdj.15 for ; Wed, 20 Aug 2014 01:36:22 -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=ZW7YTWkWu5VWtco30SkXxyNMD+KN24AUbz+ohkCGgA8=; b=KktrFnLdtTUR+65kn9wZgW5MFSMxXy2z91hF8Kak/C+TdMOPmf35KNYTRfwx0f0Nlt phKhEQkN2MOVkW5Vvkl8LhRiSEtI9lonZStUB296epHquUoIyEH8EWqryd0nmdYSWXCq 3uhE9nCII0cWiuwECRJ4WNGaxEPsYTldCIMpasPhLjLZgdo3ChenHiKrw7GEYZsrRCHQ 4ZraQUDIH7wI0pCUvMxubyAjSS5+4hfIzXC2CSG30Y0U2qAD1L0Sl2PBDgym4RwzVSEh xWNGqflMGQ9hzrtlHNUa8Jc4WRKOTsQp5qa+D+5DL4vCD90dbp5LQsCoabGuG13kOLD0 D1SA== X-Gm-Message-State: ALoCoQnLOL+tQJD+B8ueY3+cuNo3fJ8fXUfgI7vzWoHCN3xtPQqEkAYg3tqvzr41/HNeiveu0OiS MIME-Version: 1.0 X-Received: by 10.70.102.200 with SMTP id fq8mr26914423pdb.152.1408523782200; Wed, 20 Aug 2014 01:36:22 -0700 (PDT) Received: by 10.70.57.136 with HTTP; Wed, 20 Aug 2014 01:36:22 -0700 (PDT) In-Reply-To: References: <53F3743F.3000106@redhat.com> <53F3776D.2010705@redhat.com> <53F4598D.8020208@redhat.com> Date: Wed, 20 Aug 2014 08:36: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/msg00088.txt.bz2 On Wed, Aug 20, 2014 at 9:25 AM, Laszlo Papp wrote: > On Wed, Aug 20, 2014 at 9:17 AM, Pedro Alves wrote: >> On 08/19/2014 07:01 PM, Laszlo Papp wrote: >> >>> Hmm, it seems that the stripped binary on the target and the one on >>> the host were out-of-sync. This is really strange since I have not >>> changed the source code. Seems different compilations still can get >>> out-of-sync for the same code so that when I rebuild the same source >>> code, I always need to update the binary on the target, too? >> >> Ideally, if you used the exact same inputs, and the exact same tools, >> and the same exact same tool options, the output is the same. You >> can check that with md5sum, or some such. > > Thanks. I will check that next time. > >>> Anyway, now I only have problems with finding the sources file to view >>> them in cgdb. I do not know why it is wrong, but it seems to be. As >>> you can see the paths are set up for dwarf correctly: >>> >>> /usr/src/debug/foo-git/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/meh >>> >>> ... yet, gdb says src/bar.c cannot be found even though it should be >>> in the aforementioned >>> /usr/src/debug/foo-git/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/meh >>> path, provided my sysroot setting is good above, but if that was not >>> good, it would not load the binaries anyway, right? >> >> Correct. > > Thanks. > >>> So, if I set that >>> path one line above with the "-d" option to gdb, then the source file >>> can be viewed. What may be going on here? >> >> That sounds like the expected behavior, as the source directory knobs >> are independent from the sysroot setting. See: >> >> https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html > > Heh, coincidentally I started my day with reading that before, but > thanks. At least, it is a confirmation that I am on the right track. > :) > >>> Thanks in advance. I am so desperately lost. :( >> >> I think I'm lost on which part you are lost. :-) > > Well, I am not sure why it does not work. Yocto generates the images > for me, but that is not important here as long as the dwarf > information looks correct after its operation in the provided readelf > output. So, provided that the dwarf information looks correct, and the > files are there, I am not sure why gdb cannot find src/bar.c in > .../git/meh (path above). I will check "show directories" what gdb > sees in my case, but if that does not help, I am not sure how to make > it work. Got a clue? It seems to just show the default: (gdb) show directories Source directories searched: $cdir:$cwd (gdb) show substitute-path List of all source path substitution rules: (gdb) To be detailed, this is the path to the source file in question: -> ./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs/usr/src/debug/foo-git/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/foo/foo.c This is where gdb says: (gdb) c Continuing. Breakpoint 1, foo (sp=0x5e968) at foo.c:99 99 foo.c: No such file or directory. (gdb) n 100 in foo.c (gdb) Readelf says again: -> e.g. /usr/src/debug/foo-git/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/foo As you can see the two paths differ in "./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs", but that is set as sysroot when I run gdb. Do I also need to set this as a substitute path, too, then?