From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2046.outbound.protection.outlook.com [40.107.22.46]) by sourceware.org (Postfix) with ESMTPS id 9988538369E2 for ; Wed, 7 Dec 2022 23:02:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9988538369E2 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NxzxgGgWI36K7VeqFkph9f6JMMb+et2Frp2l7ZBCHSw=; b=GjqFBO5Nx4N/T8Odkt2dLZgNUvIhS4BgbkXVdCkDI2a6TAM0SHhTXQNtshOeWXeSM6sXf1xTcsM9R2F0fRJ09CCyDvwgJjzc/WupS3CdvUEF8yQIukeE1DylfcDYh0i0rMp++OyIw79hzbDFG9+wcI3Bc5P6S6CQbXOiyTpj10Y= Received: from AM6P191CA0100.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8a::41) by AS8PR08MB9044.eurprd08.prod.outlook.com (2603:10a6:20b:5c0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.11; Wed, 7 Dec 2022 23:02:14 +0000 Received: from AM7EUR03FT012.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8a:cafe::8b) by AM6P191CA0100.outlook.office365.com (2603:10a6:209:8a::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14 via Frontend Transport; Wed, 7 Dec 2022 23:02:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT012.mail.protection.outlook.com (100.127.141.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5901.16 via Frontend Transport; Wed, 7 Dec 2022 23:02:13 +0000 Received: ("Tessian outbound 58faf9791229:v130"); Wed, 07 Dec 2022 23:02:13 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f5690b21e9a513bc X-CR-MTA-TID: 64aa7808 Received: from 5efccd80c226.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3253F6DB-CB73-4559-BD85-CEE46A1784E8.1; Wed, 07 Dec 2022 23:02:06 +0000 Received: from EUR03-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5efccd80c226.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 07 Dec 2022 23:02:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HiZyYRZlU7od+EGDHSVuzxbDWPxgECLjgpeKOGaUArXukymh3O6aCJRj04eIh987tVQPllTk9NuugaE8vW+UNrJrTgA6G8tGFT4u5zc/BEvDc/uBDDu1iEAsxoc+9ETC5irkt198nT8HsgFWrtXa93tSYsyLPBBya+JRrN1yaEFDQZ87q9DUYBLlTHnSk81fHrDCJRVYP+xktNLQm2dtPwZNMGQf7b8EO8kXdFojcu3fL0ZlyfLB8k8Am2QnDuYEMYUmIcwTD7QAwDKSAGrZPRq0jv6arC0AognPXv7vB8i87v1Lb5KcMC/gn52ZrqJRsU+FwCUUhcjX6TZJ6F4eaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NxzxgGgWI36K7VeqFkph9f6JMMb+et2Frp2l7ZBCHSw=; b=gsUURqencIGX2gjlY9Vsj9zhbVVKzl5X4n6XtaOV6pOYiJxPVufinr6NQwCiMk6SlqIz/UC+E1slmnUW8GIE1sWAuC4xaY81ghMZHz2u04h1E23oMorxOMpX1TkHcbmCl5AUhLZDSa2qaM1S1tGIFOSpjKsT5B9g2ncVcn0AF9DNkT+XHfjGs/RX692nIYqZFpSBSYVjNCgfsdDQ2GIKFIEOHNSclXRXbxTGZG587wK6Fa00Lu1xNR2m07P2mU4CKpZYDM8RnPHX2t7Yp4wnn278kTDaQSEZ47KbpTTk2hkNbwpU0Hrh9HwmqXNe7k+Hdb8owhsB2STJJZs0iSq/Xg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NxzxgGgWI36K7VeqFkph9f6JMMb+et2Frp2l7ZBCHSw=; b=GjqFBO5Nx4N/T8Odkt2dLZgNUvIhS4BgbkXVdCkDI2a6TAM0SHhTXQNtshOeWXeSM6sXf1xTcsM9R2F0fRJ09CCyDvwgJjzc/WupS3CdvUEF8yQIukeE1DylfcDYh0i0rMp++OyIw79hzbDFG9+wcI3Bc5P6S6CQbXOiyTpj10Y= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by DU0PR08MB9509.eurprd08.prod.outlook.com (2603:10a6:10:44f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14; Wed, 7 Dec 2022 23:02:02 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::fe5c:b195:a2ad:b19c]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::fe5c:b195:a2ad:b19c%4]) with mapi id 15.20.5880.014; Wed, 7 Dec 2022 23:02:02 +0000 Message-ID: <013ebc82-c7de-a455-4f07-ca9c1c02170c@arm.com> Date: Wed, 7 Dec 2022 23:01:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v2 6/6] gdb/aarch64: Detect vector length changes when debugging remotely Content-Language: en-US To: Simon Marchi , Thiago Jung Bauermann Cc: gdb-patches@sourceware.org References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> <87edtdiijv.fsf@linaro.org> <0605407e-a9bf-06c1-c513-e6202181a51f@arm.com> <559069a3-f3ce-2059-bf4a-44add43979f7@simark.ca> From: Luis Machado In-Reply-To: <559069a3-f3ce-2059-bf4a-44add43979f7@simark.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0195.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::12) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DU0PR08MB9509:EE_|AM7EUR03FT012:EE_|AS8PR08MB9044:EE_ X-MS-Office365-Filtering-Correlation-Id: d434634b-6a75-47ea-95fb-08dad8a7145f x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: QV/BDYNbLNOhCZePX6f/fDjotq2LrQVkvRO+UzqwuYodEuXYf30FfLKJL7bPZ3GNY3vBkgytV8slWvF4+/UyNu+SqM9pj59wOyPWXw89nVSUm2BSRlJzj7ay32aEkQoW+k0EmKt0vHWUVV34B6/nuQA5LRX2bUHhhTvrZkEhR/0dcM/z3jqTHeixzsGHKl78qVhQNubgVZ/DxniuuxhxiIGPJxyh42S+PC5tt7VmnlSlqBBaEhZec7ZdxPjDQbvpbM3hO22456hQb5RavNwmeIsFWHdGiu0sKyxhY2fBx8ZKkwEn3E2vOJm9mXsXVNF/Ldj1rxgsWkhIQrPR+gYJnUSRUVvgLGB19ztN6lTMhlFAZLfdU4FDamODWSYPZuIro6DH8cAdzMotTJeP7wdLSdt8yfNuYa1EHV7ypFbZ24k6pq4Eik0lu+IHffISaLJ7PlnMR3hR41LY1Y6MmzZWWBWee1mlriR1JhkY4tKJcaEvB0zpm8msuhQTiTbgm5UQmSLt1H/pRPx9LwEizAlK6BD6JjgSHhKhNYIP+FbOStYaVUoTiGJaBSGXOMWmouvRrwkq96czAuo0lRPLIv+Os/xPw1CVVCu/ebSA+fuozANZoUAQIN1YSi9NUwFcaK3yai3yP5tnrGt91B8OdbP1euvSzG1fiykHDbwuekJQjlB3yzXneLVFZXbKf+O8ya/sKbh4mxUGv2yRjxrHgkdgP98BwIS0SQFSn9QHGR8DF8M= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3919.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(366004)(39860400002)(136003)(376002)(396003)(346002)(451199015)(36756003)(31686004)(2906002)(38100700002)(5660300002)(8936002)(44832011)(83380400001)(2616005)(186003)(31696002)(86362001)(316002)(478600001)(26005)(6512007)(6486002)(4326008)(41300700001)(110136005)(8676002)(66946007)(66476007)(53546011)(6506007)(66556008)(6666004)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9509 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 773b03b4-f176-49b1-63ae-08dad8a70cf8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: B3zn44cI3UEmO4jGtZdWtxx+HwTSkiZileq6HJRqbTrcHkxto/4aIwcx7+A5S55jcVaLExn1/dbztpkOPpRPpfh1b9XsDYWLJpIJdIwQtmof+1XhmY5biKW+auFmfgA+2BPEMp+ZkdEohNhehnaXVtSBoWd9kJgzPVgSM8h8NdeiJYU79h+e9VLLOjIFZclzvPga+k0s5okvA2XC08xck/3OrQXaFROlmyMZFHYHdU2vCpI5OCG2meb5sddTaifeqm/vV8otO3A8aG/ZWT8HNTbwIwd2WlR0f+rYR6fOBvl7TJq6TkGek+m4VCjj/Yl8GRcVNtkztkuqa+Nj+zCzq/tFVP9wFmMCCBP7N1VnfA2Bg+iqojdZqldRl1kxSYo5lzPBYxnpmLnkmY9EwqFo9Qu8r533HX7JT94DQKX+g8GEP/tdw00hNyfmsy8jAijSC8dGostnmPcpzNAakZQB7tElE1UxzcZt4/Zh0KBEozMS2gl44Nza792oBTsri55wkLFLFWX/zY06gGrNXcdTfLDQ4XNlPssYmHGqIREYfOI49bev6M97cCK7pzybTJyd6m52qrNo+SknHi24ORrYoPeXHN/qwJYIPn8FMqY3f6VDxJhFsDxQtQpv683k3QuZZHO046NeZKl+C+QeYreCxc2rnsOQmFpalgT2RQigveHjh3N14ysOnrYxOqy1ed+ehLxV7Brqww+cVueaF5YEJC10r9ySoebA6WmX1clFBTE= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230022)(4636009)(136003)(396003)(39860400002)(346002)(376002)(451199015)(36840700001)(40470700004)(46966006)(83380400001)(47076005)(36756003)(41300700001)(4326008)(6512007)(2906002)(186003)(8676002)(26005)(2616005)(336012)(8936002)(40460700003)(36860700001)(40480700001)(82310400005)(81166007)(356005)(31696002)(82740400003)(44832011)(70586007)(70206006)(316002)(86362001)(5660300002)(53546011)(478600001)(110136005)(31686004)(6666004)(6506007)(6486002)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2022 23:02:13.8355 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d434634b-6a75-47ea-95fb-08dad8a7145f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9044 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 12/7/22 19:25, Simon Marchi wrote: > On 12/7/22 12:05, Luis Machado via Gdb-patches wrote: >> On 12/5/22 22:37, Thiago Jung Bauermann wrote: >>> >>> Luis Machado writes: >>> >>>> On 11/26/22 02:04, Thiago Jung Bauermann wrote: >>>>> @@ -8068,6 +8078,21 @@ remote_target::process_stop_reply (struct stop_reply *stop_reply, >>>>>          /* Expedited registers.  */ >>>>>          if (!stop_reply->regcache.empty ()) >>>>>        { >>>>> +      /* If GDB already knows about this thread, we can give the >>>>> +         architecture-specific code a chance to update the gdbarch based on >>>>> +         the expedited registers.  */ >>>>> +      if (find_thread_ptid (this, ptid) != nullptr) >>>>> +        { >>>>> +          stop_reply->arch = gdbarch_update_architecture (stop_reply->arch, >>>>> +                                  stop_reply->regcache); >>>>> + >>>>> +          /* Save stop_reply->arch so that it can be returned by the >>>>> +         thread_architecture method.  */ >>>>> +          remote_thread_info *remote_thr = get_remote_thread_info (this, >>>>> +                                       ptid); >>>>> +          remote_thr->expedited_arch = stop_reply->arch; >>>>> +        } >>>>> + >>>>>          struct regcache *regcache >>>>>            = get_thread_arch_regcache (this, ptid, stop_reply->arch); >>>>>    @@ -14382,6 +14407,23 @@ remote_target::thread_info_to_thread_handle (struct >>>>> thread_info *tp) >>>>>      return priv->thread_handle; >>>>>    } >>>>>    +struct gdbarch * >>>>> +remote_target::thread_architecture (ptid_t ptid) >>>>> +{ >>>>> +  thread_info *thr = find_thread_ptid (this, ptid); >>>>> +  remote_thread_info *remote_thr = nullptr; >>>>> + >>>>> +  if (thr != nullptr) >>>>> +    remote_thr = get_remote_thread_info (thr); >>>>> + >>>>> +  if (remote_thr == nullptr || remote_thr->expedited_arch == nullptr) >>>>> +    /* The default thread_architecture implementation is the one from >>>>> +       process_stratum_target.  */ >>>>> +    return process_stratum_target::thread_architecture(ptid); >>>>> + >>>>> +  return remote_thr->expedited_arch; >>>>> +} >>>>> + >>>>>    bool >>>>>    remote_target::can_async_p () >>>>>    { >>>> >>>> Just recalled this. One deficiency of the current SVE implementation >>>> is that it doesn't have a proper way to hide the Z register when they >>>> don't have any meaningful state (SVE not active, so we have fpsimd >>>> state). >>> >>> I see the SVE_HEADER_FLAG_SVE being checked/set in >>> aarch64_linux_supply_sve_regset and aarch64_linux_collect_sve_regset >>> (though in the latter it is set unconditionally), and also HAS_SVE_STATE >>> being used in aarch64_sve_regs_copy_to_reg_buf and >>> aarch64_sve_regs_copy_from_reg_buf. >>> >>> But I wasn't able to find similar logic regarding hiding the Z >>> registers. Do you have any pointers? >>> >> >> There isn't logic to do that at present. This is something I'm pondering for SME, and would possibly apply to >> SVE as well. But it may be more complicated than useful. >> >>>> Given the VL will always be reported as > 0, even if there is no >>>> active SVE state, gdb will always attempt to show Z registers. And >>>> those are quite verbose. >>> >>> The VG pseudo-register is defined with an int type, so we could return a >>> negative value to indicate that the Z registers are unused (and the >>> module of the value would still be the vector granule). Would that >>> be ok? >> >> I think a value of 0 would be fine for this purpose but... >> >>> >>>> In this sense, the implementations of the the thread_architecture >>>> methods for both native aarch64 and remote differ. While native >>>> aarch64's implementation is capable of detecting the lack of active >>>> SVE state, the remote implementation can't. If gdbserver decided to >>>> drop the Z registers mid-execution (before the SVE state is not >>>> active), there wouldn't be vg for gdb to make a decision. >>> >>> Looking at aarch64_linux_nat_target::thread_architecture my impression >>> is that its result depends only on aarch64_sve_get_vq, so I don't see >>> how it's different from the remote implementation. >> >> ... Right, but for native debugging we actually call ptrace to extract the vector length. That is completely independent from >> the XML target description or the available register sets. >> >> In the case of remote debugging, the expedited registers are returned based on an existing register description. >> >> Take, for example, the following: >> >> - SVE state is enabled and we have the vg register. >> - Program updates the SVE vector length and, as a result, we no longer have an active SVE state (reverted to FPSIMD state) >> - GDB drops the sve feature from its target description. >> - Program executes a sve instruction and SVE state is made active. >> - gdbserver tries to tell gdb what the value of vg is, but gdb doesn't know anything about vg at this point, because it has dropped the sve feature previously. >> >> I think this is the downside of using expedited registers to communicate the architecture changes. For this case, returning a full XML would make it easy for gdb to >> figure things out. >> >> But, going back to hiding sve/sme registers when they're not in use, I'm not yet sure that is something we should pursue. >> >> I'd say if you manage to get things working with the expedited registers (for the problematic cases Simon and I pointed out), that's fine. > > Reading this, I thought of another potential problem with using > expedited registers to communicate the architectures change. When using > the non-stop version of the remote protocol, we will have a stop reply > for each thread that stops, so that's fine, we can infer each thread's > tdesc. But with the all-stop variant of the protocol, you only get a > stop reply for one thread, for a given stop. I wasn't sure about this case, so I mentioned it in the first reply to patch 6/6. Isn't it possible to send back information about all the threads that have stopped in all-stop mode? > > For instance, imagine you have two threads, thread 1 hits a breakpoint. > GDB gets a stop reply for thread 1, and thread 2 is just considered stop > because we're using the all-stop remote protocol. If we need to read > thread 2's registers, we would need to know its tdesc. Its vg may have > changed since last time, or it might be the first time we learned about > it. In that case, I don't think we have a way out of adding some mean > for gdbserver to tell gdb which tdesc applies to that thread. > > If it's the case, that we need to extend the RSP to allow fetching > per-thread tdesc, here's the idea I had in mind for a while, to avoid > adding too much overhead. Stop replies and the qXfer:threads:read reply > could include a per-thread tdesc identifier. That tdesc identifier > would be something short, either an incrementing number, or some kind of > hash of the tdesc. It would be something opaque chosen by the stub. A > new packet would be introduced to allow GDB to request the XML given > that ID. On the GDB side, GDB would request the XML when encountering a > tdesc ID it doesn't know about, and then cache the result. The > additional overhead would be: The aarch64 port uses feature hashes for the target descriptions. We could leverage that, but we would need to keep the hash stable so older gdb's that don't know about certain features don't break/get confused. > > - fetching each XML tdesc once, that seems inevitable (we just don't > want to fetch the same XML tdesc over and over) > - a few characters more in stop replies and qXfer:threads:read replies > > I believe this could be implemented in a backwards compatible way > without even adding a new qSupported feature. XML is extensible by > nature. And stop replies are too. The T stop reply doc says: > > Otherwise, GDB should ignore this ‘n:r’ pair and go on to the next; > this allows us to extend the protocol in the future. > > So in theory we could add a `tdesc-id:1234` field without breaking old > GDBs. However, those old GDBs would break when trying to read registers > of threads with unexpected SVE lengths. It sounds like a good approach to me, and slightly better than using the expedited registers. It would be nice if we could minimize the amount of tdesc-id entries for all the threads, if they're mostly the same. The most obvious case is having hundreds of threads that all have the same tdesc-id. It wouldn't be nice to duplicate all that data. Originally we discussed a packet to ask the remote if the target description had changed. If nothing's changed, it is a quick reply. I suppose we could have something similar to that here as well, to optimize things, that is, don't return data if nothing's changed. > > Simon