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

Tom de Vries
2025-10-07T13:09:12Z

On 10/7/25 14:21, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
>
>> On 10/3/25 21:15, Tom Tromey wrote:
>>> Andrew> Add a new Corefile.mapped_files method which returns a list of
>>> Andrew> gdb.CorefileMappedFile objects.
>>>
>>> Andrew> Each gdb.CorefileMappedFile object represents a file that was mapped
>>> Andrew> into the process when the core file was created.
>>>
>>> Andrew> + ** New Inferior.corefile attribute. This read only attribute
>>> Andrew> + contains the gdb.Corefile object if a core file is loaded into
>>> Andrew> + the inferior, otherwise, this contains None.
>>>
>>> This hunk is duplicated, it also appears in patch 1.
>>>
>>> Other than that this looks good to me.
>>> Approved-By: Tom Tromey <tom@tromey.com>
>>
>> Hi,
>>
>> Starting with this commit, I see:
>> ...
>> (gdb) check-build-ids^M
>> Python Exception <class 'AssertionError'>: build-id mismatch for
>> /lib64/libc.so.6^M
>> Error occurred in Python: build-id mismatch for /lib64/libc.so.6^M
>> (gdb) FAIL: gdb.python/py-corefile.exp: test mapped files data:
>> check-build-ids
>> ...
>
> So that test is checking that the build-ids of the objfiles that were
> loaded match the build-ids pulled from the corefile.
>
> For example, GDB should find a build-id for `/lib64/libc.so.6` in the
> core file, then when GDB loads `/lib64/libc.so.6` an objfile is created,
> we can also read the build-id via the objfile.
>
> The failure tells us that for some reason these two methods to read the
> build-id gave different results.
>
> Now, `/lib64/libc.so.6` must have a build-id, otherwise the objfile
> would return None for its build-id, and the check-build-ids command
> would ignore this library and we shouldn't see an assert.
>
> So for the assert to trigger one of these things must have happened:
>
> + Build-id is present in the core file, but GDB failed to extract it,
> or extracted the wrong data. Resulting in either None, or a different
> build-id, or
>
> + Build-id is not present in the core file, GDB will return None for
> the build-id.
>
> Of these two I suspect the second; for a period of time the GNU linker
> was ... changed ... such that it no longer placed the build-id within
> the first page of a generated ELF, as a result, the Linux kernel would
> not include the build-id in core dumps.
>
> We can check for the second case using:
>
> readelf -WS /lib64/libc.so.6 | grep build-id
>
> The output will be something like:
>
> [ 2] .note.gnu.build-id NOTE 0000000000000370 000370 000024 00 A 0 0 4
>
> It's the '000370' column we're interested in. If this value is greater
> than a page size, then GDB isn't going to be able to find the build-id.
>

Hi Andrew,

it seems to be the second case indeed:
...
$ readelf -WS /lib64/libc.so.6 | grep build-id
[22] .note.gnu.build-id NOTE 00000000001fa178 1fa178
000024 00 A 0 0 4
...

Sofar, I've only encountered this problem on Tumbleweed (
https://bugzilla.suse.com/show_bug.cgi?id=1240689 ), this is the first
test-case for which I run into it on Leap 15.6. But they have the same
linker base version: 2.43.1 (though soon to be upgraded, AFAIU), so that
makes sense.

> You could try applying the patch below. This isn't a real fix, but does
> two things:
>
> 1. Ignores any None build-id values pulled from the core file. I
> suspect this will be enough to get the test passing for you, but
> the patch also does
>
> 2. prints both build-ids if there is a mismatch.
>
> Unfortunately just doing (1) isn't a long term fix as this would also
> ignore the case where a bug in GDB means that we fail to find the
> build-id.
>

Ack.

> So what I'm going to do is try to extend the test so that we can use
> maybe readelf like I show above to check if GDB _should_ be able to find
> the build-id, and only run the build-id check _if_ we think GDB should
> be able to find the build-ids.
>

FWIW, there are a few other test-cases that could benefit from such a
mechanism as well.

> Anyway, I'd be interested to hear if the patch resolves the failure for
> you. If it doesn't then I'm on completely the wrong path and will need
> to rethink.

The patch does fix this.

And FWIW, reverting part 1 gives us:
...
(gdb) check-build-ids^M
Python Exception <class 'AssertionError'>: build-id mismatch for
/lib64/libc.so.6; 16dc6ffdd6165c6cb0346d683a041c90daa99730 vs None^M
Error occurred in Python: build-id mismatch for /lib64/libc.so.6;
16dc6ffdd6165c6cb0346d683a041c90daa99730 vs None^M
(gdb) FAIL: $exp: test mapped files data: check-build-ids
...

Thanks,
- Tom

> Thanks,
> Andrew
>
> ---
>
> diff --git i/gdb/testsuite/gdb.python/py-corefile.py w/gdb/testsuite/gdb.python/py-corefile.py
> index cffd037a23b..979a0281d12 100644
> --- i/gdb/testsuite/gdb.python/py-corefile.py
> +++ w/gdb/testsuite/gdb.python/py-corefile.py
> @@ -101,9 +101,12 @@ class CheckBuildIds(gdb.Command):
> p = pathlib.Path(m.filename).resolve()
> b = m.build_id
>
> + if b is None:
> + continue
> +
> if p in path_to_build_id:
> count += 1
> - assert path_to_build_id[p] == b, "build-id mismatch for %s" % p
> + assert path_to_build_id[p] == b, "build-id mismatch for %s; %s vs %s" % (p, path_to_build_id[p], b)
>
> assert count > 0, "no mapped files checked"
>
>