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/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 for the diagnostic help.  I'll work on improving the test to try
and catch these cases.  If that works, then we might be able to adopt
this to help with other tests.  Keeping this in mind, I'll add helper
functions to lib/gdb.exp.

Thanks,
Andrew