From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D038C54EE9 for ; Thu, 22 Sep 2022 13:58:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231709AbiIVN6Z (ORCPT ); Thu, 22 Sep 2022 09:58:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231935AbiIVN6N (ORCPT ); Thu, 22 Sep 2022 09:58:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C15A9EF08A for ; Thu, 22 Sep 2022 06:58:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 84FD7B83708 for ; Thu, 22 Sep 2022 13:58:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87F57C433D6; Thu, 22 Sep 2022 13:58:00 +0000 (UTC) Date: Thu, 22 Sep 2022 14:57:56 +0100 From: Catalin Marinas To: Luis Machado Cc: Mark Brown , Will Deacon , Shuah Khan , Shuah Khan , Alan Hayward , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v4 3/4] arm64/ptrace: Support access to TPIDR2_EL0 Message-ID: References: <20220829154921.837871-1-broonie@kernel.org> <20220829154921.837871-4-broonie@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org 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