On Thu, Sep 22, 2022 at 12:15:13PM +0100, Luis Machado wrote:
> 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.
That's fine. Looking at the ptrace_regset() implementation in Linux, it
updates the user iov_len to what was actually copied. In this case it
would be 1 (the minimum of the user iov_len and the regset n * size). So
from the old gdb ABI perspective, it shouldn't notice a difference. An
old gdb setting the TLS reg will also leave tpidr2_el0 unchanged.
An updated gdb running on an older kernel should be aware that even if
it asked for two u64, it may only get one back and the user iov_len
updated accordingly.
--
Catalin
