From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7698 invoked by alias); 20 Aug 2014 08:39:59 -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 7686 invoked by uid 89); 20 Aug 2014 08:39:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pa0-f46.google.com Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 20 Aug 2014 08:39:58 +0000 Received: by mail-pa0-f46.google.com with SMTP id lj1so11802178pab.19 for ; Wed, 20 Aug 2014 01:39:53 -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=yD82nSTeiHFAJyoT9Zmms6bQgKr5HD5ZB2rBkQhpWgc=; b=KXEUVNq7e22TyKBawoMGDRej0MLp5hE62GbtbOX0bH0PiYf7MfIMLOtdt161IYK6zT iNFxtWuXvr6n+MeHk9DDOocac7kU7iSdMdbR6X13BQG0A578WSpXvUHZFef7tUI4+CTX F6+ABV2Yoc+7emnJFSae1cev1G8d9qYAH+lEMeCieb5Ld2Ys8WMPmUFRqbVFm0E+Vx+5 LAPLl8ayEkvTWOeY4y4g7/LlWC1jo2UJObKZrAI23YB4eWa/R+BPHaoRs42rPTRwjaso bSiA4xVEd2k5hocPhaRL5VoZOWhtQy9T1wgKq5Ijz/q+YFIaHhF+9RlStvhzuhPA6zI/ skkw== X-Gm-Message-State: ALoCoQlJMZLDFNt7QSjRzHSRKKqyxt6SYJRjJgaLGSzWSBblbD5n4oUtZDmJ7PscI6lDnZhzG47h MIME-Version: 1.0 X-Received: by 10.70.134.140 with SMTP id pk12mr20327085pdb.165.1408523990762; Wed, 20 Aug 2014 01:39:50 -0700 (PDT) Received: by 10.70.57.136 with HTTP; Wed, 20 Aug 2014 01:39:50 -0700 (PDT) In-Reply-To: References: <53F3743F.3000106@redhat.com> <53F3776D.2010705@redhat.com> <53F4598D.8020208@redhat.com> Date: Wed, 20 Aug 2014 08:39: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/msg00089.txt.bz2 On Wed, Aug 20, 2014 at 9:36 AM, Laszlo Papp wrote: > 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? Oh, and more thing to provide as much information as possible to you: (gdb) info source Current source file is foo.c Compilation directory is /usr/src/debug/foo-git/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/foo Source language is c. Compiled with DWARF 2 debugging format. Does not include preprocessor macro info. (gdb)