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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux