Re: [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method

[Andrew Burgess <aburgess@redhat.com>]

Tom Tromey <tromey@adacore.com> writes:

>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew>   + Build-id is not present in the core file, GDB will return None for
> Andrew>     the build-id.
>
> Andrew> Of these two I suspect the second; for a period of time the GNU linker
> Andrew> was ... changed ... such that it no longer placed the build-id within
> Andrew> the first page of a generated ELF, as a result, the Linux kernel would
> Andrew> not include the build-id in core dumps.
>
> Andrew> We can check for the second case using:
>
> Andrew>   readelf -WS /lib64/libc.so.6 | grep build-id
>
> Andrew> The output will be something like:
>
> Andrew>   [ 2] .note.gnu.build-id NOTE            0000000000000370 000370 000024 00   A  0   0  4
>
> Andrew> It's the '000370' column we're interested in.  If this value is greater
> Andrew> than a page size, then GDB isn't going to be able to find the build-id.
>
> I have a question about this work.
>
> There's an internal AdaCore test that creates a core file, then uses
> 'file' on a different executable and 'core' to check if a warning is
> issued.
>
> gdb 16 on this test does:
>
> (gdb) core core
> warning: core file may not match specified executable file.
> [...]
>
> However with git master we don't get that.
>
> Now, the executables in question do have build ids:
>
> bapiya. readelf -WS call_crash|grep build-id
>   [ 2] .note.gnu.build-id NOTE            0000000000000390 000390 000024 00   A  0   0  4
> bapiya. readelf -WS crash|grep build-id
>   [ 2] .note.gnu.build-id NOTE            0000000000000390 000390 000024 00   A  0   0  4
>
> ... and I verified the the IDs are actually different.
>
> I'm not really sure how to find the relevant page size, per your comment
> above.
>
> I can't readily tell if the core file has an ID.  gdb thinks there
> isn't, using the command from py-corefile.py.
>
> That by itself seems a little weird but I am wondering if the warning
> should appear anyway, at least in this case, because the core file
> records it was created by 'crash' but the current file has a different
> base name ("call_crash").
>
> IOW, is the lack of a warning in this case now intentional?

No this is not intentional, and I can reproduce this.

But I thought we had a test that covered this specific case already, so
I'm really surprised this wasn't flagged during testing.

I'll investigate what's going on here, I guess I've managed to break
something....

>
> And, how can I understand why the ID isn't in the core?
> I'm having some trouble figuring out which 'ld' the compiler is invoking.

The offsets of those build-ids looks fine (less than 0x1000) so should
be within the first page of the ELF.  This will be something I've
managed to break somehow :(

Sorry about that.

Thanks,
Andrew