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

[Simon Marchi <simark@simark.ca>]

On 2/26/24 17:34, Thiago Jung Bauermann wrote:
> 
> Tom de Vries <tdevries@suse.de> writes:
>> 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).
> 
> I did a bit of digging today and the $tpidruro register isn't available
> via ptrace in the 32-bit Linux kernel, but it is available for an
> aarch32 program running under an arm64 Linux kernel via the ptrace
> compat interface.
> 
> Support for this isn't implemented in GDB however, so at least for now
> IMHO it makes sense to disable the org.gnu.gdb.arm.tls feature in
> arm-linux and arm-netbsd (which from a quick look at arm-netbsd-nat.c
> also doesn't seem to support accessing $tpidruro either).
> 
> I'm testing a patch that does this and I'll post it if there are no
> regressions.

Thanks, I think that would make sense.

The only time we should be seeing some "unavailable" registers or memory
is in the context of tracepoints, for things that are not collected.
Seeing an unavailable register here is a sign that something is not
right.

Simon