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

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

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
>