Re: Debugging issue with gdbserver and a daemon on the target

[Laszlo Papp <lpapp at kde dot org>]

On Wed, Aug 20, 2014 at 9:25 AM, Laszlo Papp <lpapp@kde.org> wrote:
> On Wed, Aug 20, 2014 at 9:17 AM, Pedro Alves <palves@redhat.com> 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?