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

[Tom de Vries <tdevries@suse.de>]

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"
>   
>