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

Andrew Burgess
2025-10-07T12:22:09Z

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.

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.

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.

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.

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"