Re: [PATCH v4 3/4] arm64/ptrace: Support access to TPIDR2_EL0

[Luis Machado <luis.machado@arm.com>]

On 9/19/22 13:43, Mark Brown wrote:
> On Fri, Sep 16, 2022 at 01:01:31PM +0100, Catalin Marinas wrote:
>> On Mon, Aug 29, 2022 at 04:49:20PM +0100, Mark Brown wrote:
>>> @@ -1392,7 +1407,7 @@ static const struct user_regset aarch64_regsets[] = {
>>>   	},
>>>   	[REGSET_TLS] = {
>>>   		.core_note_type = NT_ARM_TLS,
>>> -		.n = 1,
>>> +		.n = 2,
>>>   		.size = sizeof(void *),
>>>   		.align = sizeof(void *),
>>>   		.regset_get = tls_get,
> 
>> Does this change confuse user-space? I presume an updated gdb would
>> check the iov.len to figure out whether a new register is available but
>> would existing debuggers complain of the new size of this regset?
> 
> gdb seems happy as far as I can see, it is possible something would be
> reusing the read_iov for repeated TLS read calls in a context where it
> was only pointing at a single u64 but I'm not sure how realistic that
> is given the idiom.  I did do a search on sources.debian.net and didn't
> turn up anything that'd have problems.
> 
> If using this as an extensiblility mechanism is a concern we need to
> bear that in mind elsewhere, and for this it's either a case of
> providing another single register regset or trying to do a generic
> sysreg read/get (though that'd be another regset that's not idiomatic
> for the regset API).
Older GDB's assume a single register for NT_ARM_TLS, so they will always
fetch TPIDR. Newer GDB's will check the size and act accordingly.