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

[Laszlo Papp <lpapp@kde.org>]

On Wed, Aug 20, 2014 at 9:36 AM, Laszlo Papp <lpapp@kde.org> wrote:
> 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?

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)