Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

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

On 3/4/24 16:25, Luis Machado wrote:
> On 2/18/24 13:30, Tom de Vries wrote:
>> On 2/18/24 05:09, Kevin Buettner wrote:
>>> Hi Tom,
>>>
>>> On Tue, 13 Feb 2024 18:17:18 +0100
>>> Tom de Vries <tdevries@suse.de> wrote:
>>>
>>>> On arm-linux, with a started hello world, running "info frame" works fine, but
>>>> when I set debug frame to on, I run into:
>>>> ...
>>>> (gdb) info frame
>>>>     ...
>>>> [frame] frame_unwind_register_value: exit
>>>> value is not available
>>>> (gdb)
>>>> ...
>>>>
>>>> The problem is here in frame_unwind_register_value:
>>>> ...
>>>>             if (value->lazy ())
>>>>               gdb_printf (&debug_file, " lazy");
>>>>             else
>>>>               {
>>>>                 int i;
>>>>                 gdb::array_view<const gdb_byte> buf = value->contents ();
>>>> ...
>>>> where we call value->contents () while !value->entirely_available ().
>>>>
>>>> Fix this by checking value->entirely_available () and printing:
>>>> ...
>>>>       [frame] frame_unwind_register_value:   -> register=91 unavailable
>>>> ...
>>>>
>>>> Tested on arm-linux.
>>>
>>> The fix looks good to me.
>>>
>>> I'm wondering about the test case though.  Is it the case that the
>>> failure depends on debug info from a particular compiler (or compiler
>>> version)?  If so, would it be possible to devise a test using the
>>> DWARF assembler which would not be dependent on compiler output that
>>> may change over time?
>>>
>>
>> Hi Kevin,
>>
>> thanks for the review.
>>
>> This doesn't depend on debug info.  The test-case depends on a register being unavailable.  I don't know if or how we can reliably enforce this condition in a test-case.
>>
>> To give some more detail, a minimal way to show the register as unavailable is:
>> ...
>> $ gcc hello.c
>> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
>> Temporary breakpoint 1 at 0x512
>>
>> Temporary breakpoint 1, 0xaaaaa512 in main ()
>> $1 = <unavailable>
>> ...
>>
>> I'm not sure why it's unavailable.
>>
>> It seems the register was added as part of some tls support for fbsd arm tdep.  It could be that support for the register is missing in linux arm tdep.
>>
>> It also could be a kernel problem (used kernel is 4.4.190).
>>
>> Or, something to do with the fact that I'm running a pinebook with 64-bit kernel, 32-bit userland setup.
>>
>> Luis, any comments on this?  Is this a bug, or a missing feature, or expected behaviour?
>>
>> Thanks,
>> - Tom
>>
>>> Kevin
>>>
>>
> 
> Hi Tom,
> 
> I was out on time off. It looks like Thiago addressed this in a separate thread, is that right?

Hi Luis,

welcome back :)

Thiago addressed removing the "<unavailable>" register.

I took the opportunity of having an "<unavailable>" register available 
to improve gdb behaviour in presence of such a register.

This patch is an example of that, as well as 
https://sourceware.org/pipermail/gdb-patches/2024-March/206965.html .

Thanks,
- Tom