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

[Andrew Burgess <aburgess@redhat.com>]

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"