From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30515 invoked by alias); 20 Aug 2014 09:10:05 -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 30406 invoked by uid 89); 20 Aug 2014 09:10:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pd0-f173.google.com Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com) (209.85.192.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 20 Aug 2014 09:09:59 +0000 Received: by mail-pd0-f173.google.com with SMTP id w10so11559195pde.4 for ; Wed, 20 Aug 2014 02:09:58 -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=zvrLfqEw7TiYUJJQEnfndyjrwiE6F3ScSZUzjleIxWU=; b=GKc8l8SVKItySTXwbD7nm+AwH5kAsFR76+tmMYuG+D0d6ef9YogsgCFxJAsNzXcanJ Z/iR7HqI/re43kKmqp4EnJNqGq8yG6FAteCT/nnq4JjVoQxF2A0qOWCl1yhaPf+RBIcY 41RrqtrNjuBFC002Z5Y+/2G5wf118gYguEojqPhBpnIqfUWCPCtidxGM1foXVW1heYxR meRvEYQuGGhPJI5ClbNCFIlAZ3OTcufsvqkHTndsSek4+rL4EdX+WSuvtZLl7hEBfwto 2Ug1Aj75bpfDCF9As6HrrnZTVPaQMFq2aYltGol6BG51YO0LDjnTwa+Bdhh8S6Q4zW1A Btdg== X-Gm-Message-State: ALoCoQmkGhLtOVW6dfUefduQyxxU/LvdQviT8jaMvFQz8Q5NqLlajd0NgAkJovM9Z49XChoKyS/0 MIME-Version: 1.0 X-Received: by 10.66.196.65 with SMTP id ik1mr20855931pac.154.1408525795772; Wed, 20 Aug 2014 02:09:55 -0700 (PDT) Received: by 10.70.57.136 with HTTP; Wed, 20 Aug 2014 02:09:55 -0700 (PDT) In-Reply-To: References: <53F3743F.3000106@redhat.com> <53F3776D.2010705@redhat.com> <53F4598D.8020208@redhat.com> Date: Wed, 20 Aug 2014 09:10: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/msg00091.txt.bz2 On Wed, Aug 20, 2014 at 9:39 AM, Laszlo Papp wrote: > 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) This made it work, but is it the best thing to do? -ex "set substitute-path /usr/src/debug/ ./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs/usr/src/debug/" Also, can someone verify that it is also supposed to work if I just use directories as claimed in here? I cannot because it does not work in my version, but it is not the latest! http://stackoverflow.com/questions/1103161/gdb-searching-for-source-directories/1327343#comment35550119_1327343 If yes, which one to use?