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

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

On 2/26/24 23:41, Simon Marchi wrote:
> 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.

In that case, I've filed a PR ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=31418 ) to track this 
problem.

Thanks,
- Tom