From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on2082.outbound.protection.outlook.com [40.107.105.82]) by sourceware.org (Postfix) with ESMTPS id 28C393858D28 for ; Fri, 10 Feb 2023 14:57:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 28C393858D28 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=HKXSJ9Ner3xGS/VI5qY3AG/p6wIl0qH1IkwfsOCj/7k=; b=dBh6xRtuRuIO/uqd/FXcao+pdm5jNc4qrPP9CEJ/eTHwkOmc038JZ27G9hZreE8iTLpxKznSLO2bN42Ls6jfP0pmX9/CtYs8H/nYBq301ivzBSKXSsdOZ0BguqcOiMoyVizUI/HOElrZYOvTIYyDUTl24BjcjUNLaWwDKzLbXS4= Received: from DUZPR01CA0204.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b6::25) by AS8PR08MB7766.eurprd08.prod.outlook.com (2603:10a6:20b:526::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.19; Fri, 10 Feb 2023 14:57:02 +0000 Received: from DBAEUR03FT058.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:4b6:cafe::c5) by DUZPR01CA0204.outlook.office365.com (2603:10a6:10:4b6::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.21 via Frontend Transport; Fri, 10 Feb 2023 14:57:02 +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 DBAEUR03FT058.mail.protection.outlook.com (100.127.142.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.19 via Frontend Transport; Fri, 10 Feb 2023 14:57:02 +0000 Received: ("Tessian outbound baf1b7a96f25:v132"); Fri, 10 Feb 2023 14:57:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 047e4f2b3c9aedd0 X-CR-MTA-TID: 64aa7808 Received: from f7a345fa60bb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8E65B098-ABB2-49BD-9FC0-6F45E126F5E1.1; Fri, 10 Feb 2023 14:56:55 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f7a345fa60bb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 10 Feb 2023 14:56:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XTBCSO9NZ7DCkkbAbBIMU4OLobuMZhEJ59LzikaAtVyDRSVd5fIpkg7cRRnpi+ErkDG816Ej+0LvOeHU0nObHL/DxhmRKJ4g6o52ukQXZSnCKD9gZH1sWNRpR0NRpAqyyGcaKRg0BWARx1iJJAkOTFTjH97G3CbmpENavW1Fbek0ZGXclRl4wekvDznJUuIB/ki7ygAkXrqqXv0HWjXEYGb3ImIR6jIE/q3IGzuoks6hRVqEM7ku4NA0vyqrwCl7xrDdVtkeDXFVqBiVHJK+hUoOKsjvIiI0vt9glaeWZaZ15V4/g0KGDpRPmSm69HrlGu6oxwPXzGI43l++KnWDFQ== 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=HKXSJ9Ner3xGS/VI5qY3AG/p6wIl0qH1IkwfsOCj/7k=; b=cO6JqhpnM97GbT/rel0IM/EPFzI7Ff8dmU5XvIbg0HBrT5PIt0l9pxjzje2L9KghrxdaS1P0fRH8DTej/+sYWo4h5liM4m3tEqQB9WjCbZ3dANVJiQ/wwiXDgOfcnvz8Df2YMMPnaTGCwf8znAP0MNDkWKJTI9+VBdBULD9VRwIynb0l1O2WJF7rl/fSWNn1Q4zv0kTs6ekUbe4ySBM8KOThmKijgn72fh1JhCAkml6kIDakDdmMJKVIQFEQT6RlC1zmK42w71Ktx49ijuJ0JuNsNBmr9pVLujiGKW3nezzQ+nTpy6mipbc2GqpI2nRyRakV4k38zxvwbaCR7vxEYw== 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=HKXSJ9Ner3xGS/VI5qY3AG/p6wIl0qH1IkwfsOCj/7k=; b=dBh6xRtuRuIO/uqd/FXcao+pdm5jNc4qrPP9CEJ/eTHwkOmc038JZ27G9hZreE8iTLpxKznSLO2bN42Ls6jfP0pmX9/CtYs8H/nYBq301ivzBSKXSsdOZ0BguqcOiMoyVizUI/HOElrZYOvTIYyDUTl24BjcjUNLaWwDKzLbXS4= 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 VE1PR08MB5664.eurprd08.prod.outlook.com (2603:10a6:800:1ae::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.21; Fri, 10 Feb 2023 14:56:53 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6%7]) with mapi id 15.20.6086.019; Fri, 10 Feb 2023 14:56:53 +0000 Message-ID: <9864aa2b-f3cc-94ae-0785-5565cc990006@arm.com> Date: Fri, 10 Feb 2023 14:56:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description Content-Language: en-US To: Thiago Jung Bauermann , Simon Marchi Cc: Pedro Alves , Andrew Burgess , Thiago Jung Bauermann via Gdb-patches References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-5-thiago.bauermann@linaro.org> <87pmattzjw.fsf@redhat.com> <7970ac03-1123-d5f6-7b17-808832d43be6@simark.ca> <9a85e2fe-078a-e2ee-7e49-53fe0ceef492@arm.com> <87y1pgaib6.fsf@linaro.org> <3f4e3603-59e3-a896-72e4-d692646c4e44@palves.net> <87v8kd9odi.fsf@linaro.org> <87cz6i2o6x.fsf@linaro.org> From: Luis Machado In-Reply-To: <87cz6i2o6x.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0014.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::15) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|VE1PR08MB5664:EE_|DBAEUR03FT058:EE_|AS8PR08MB7766:EE_ X-MS-Office365-Filtering-Correlation-Id: 0419cb0b-8343-485a-5118-08db0b77115c 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: PvcnA2lNfOoTBlcpnoyseCvZtgindSU21oy1rtDZYx2bMHRUsG1P5xD4C8YTC+Rard+crqpG5GNy+YNBPqZpLYS/b2soprqbwcOGNJjAb4qycbvg8jmhRc3GXVbckq5Z4e8hjqj5EMB091l82dP6aHym9SXAeifz1ND/G51xURF2v8TIpib4B86QL6u5WkftF/5u+bfmVuTdhrW/j7unIJ/5hkzvcJpttb5YYQr0EnhJPAHsY0vmqD8HWits5c0aVFt3Gz7ltvRxcF1oGjdLf7JAONaQeHKtDWJQc3ALW9XhmdkIwokHLHl7XoZE4DpeNjbj5qhmSheR5gndMWRGZk2eyCojQ256v1n3FUCo7pl6oE4nOpUlxFfdey+r013+xpw8Gpdo62Z3kSEjXgGFC7NEghX6938CsNDXD+cLol6YIjgo/mtAXMx+MjYFRo35RrPm44mRWz035SIovahUTBMqzBO2tLtMi+7x043RoHgEBLwnFxKeSYubydKtm7puhK1nR5mUQufnGaStAv6mBDk+BaC1wtxFnvHG4ZSDuqwRWu+dZlP/DTA7MMEvT6VBq+F3ZmPnwYtqpBzibn34gizRWy9YuFPXtqZ4nUUHbh267M230l/LCTXjM29F5gAt6kVLRFjb7q0ekr4vX2sL9EZJD5XaDQ/BKGRv8pc1IkEqPBNgQf2Rx1KJsx+ypiL5mr4ZQ6x1qt4UvnBer/7YzEBbQQvrHHX5KjnYYGTok1k= 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:(13230025)(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(451199018)(31686004)(6512007)(2906002)(40140700001)(36756003)(110136005)(38100700002)(54906003)(478600001)(66556008)(41300700001)(8676002)(6486002)(66946007)(66476007)(4326008)(31696002)(6506007)(26005)(53546011)(186003)(2616005)(8936002)(44832011)(316002)(5660300002)(86362001)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5664 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: DBAEUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1fb7268f-c306-4db2-1ce9-08db0b770b86 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yxIk1SJsAUAVRMB4iNFGdGbZkuqA+tvRfhc695LqiUM4BXAdui/aUBnNcPqr9NAN0qQ/wBI5FOIZe46IHstB64h2QYg3d5hNPo23MZrrqN+N5HXTyMetuK6yYU5/bjOAv9W3bZ3udNMe4s0Q7euCoM7tQOwAgXfZT/7dPQIIrRcKlA8qILOC512GHo90HtKck7Jf7/1ufrV1TeFNLcxxSyXjOTj8Kpgl4yc2T7JwPAN1UJEr1N6yCQt5D3So6ay5rhl+s8p/cFRuRirkOg0Ofrl5T+qHn/8VYk6QkTLRxAwP2KHPesExLuT382P9eIZT4ZwYps4b2oRwR7hdJv57/oGfRrooaMmZZLKGeFdGiG0bHZM/FkSb9kS+S9vWuykLwrGMYY5RnnvMT+RIBwCTCLzGqd06FspyXrg2VS24F6CqMLu0poG7jh3VavDVvskKjM4dTqF6muao/EeiXIJfm6//cKwkaEtCjuDe726jvmGW7MqgVzV/R2s5q2rRSogzyKNownwt82EQzTIRp/D9a3RUDPb1din6K84MuK+6sJPpNW/jgrDbOfeFJ71XZsq8YJEthnGamlcJbS/8XHuM9Lh16Az8vO7nLmMV3BbvbI/590bVvmFkrfoxiiEC22m+A8AMeXhYhNtuiLnsTz7z75tme2303aUOc1FJZ/CbLg4yHBK33vl+kYSWbT3pVtOY10Gtb9Yff+BZqLB0Ly+XKVSXJLPLAbauhNMEy2j61ree7jXD8YVIa+BS+6gRx9Fkc5Bp23rt00Pbc4PefxDZYVPSp6/UX8ZP2PViwrYWcX0= 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:(13230025)(4636009)(346002)(376002)(39860400002)(136003)(396003)(451199018)(36840700001)(40470700004)(46966006)(82310400005)(36756003)(36860700001)(2616005)(53546011)(6486002)(40140700001)(2906002)(40460700003)(54906003)(356005)(31686004)(110136005)(336012)(31696002)(47076005)(70206006)(8676002)(41300700001)(70586007)(186003)(6506007)(6512007)(26005)(478600001)(8936002)(40480700001)(86362001)(82740400003)(81166007)(4326008)(316002)(44832011)(5660300002)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2023 14:57:02.3177 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0419cb0b-8343-485a-5118-08db0b77115c 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: DBAEUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7766 X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,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 2/10/23 03:29, Thiago Jung Bauermann wrote: > > Simon Marchi writes: > >>> That is, assuming we continue with the thread-specific tdesc approach >>> rather than the one which expands tdescs to allow describing one >>> register's type in terms of another one. I'll revisit my notes and think >>> more about this. >> >> Can we expand about this idea? I think I like it, but I don't see 100% >> how it would work. > > Sorry, I can't expand much on it. I like it too, and as I mentioned in > another email I spent some time investigating how it could be done but > I wasn't able to make progress so I decided to do the per-thread tdesc > implementation instead. > > I would be willing to try again but I would need help with high-level > design. > My take on it is that it is he appropriate solution, and it would allow us to have a single target description for all the threads. But it is also a larger effort that has to revamp some things in gdb's type system to allow for sizeless types, and that also has implications in other areas of gdb. Also, quite a bit of effort was put into supporting dynamic vector lengths mid-execution for SVE in native gdb, including some new target hooks to adjust the architecture and the register cache format. Changing this also means having to support the debugging stubs out there that already support SVE target descriptions. One can say those stubs are not fully functional in terms of supporting dynamic vector lengths mid-execution, but they already produce target descriptions in the current format (gdbserver is one of those stubs and QEMU is probably the second most important). I'd be happy with an intermediate solution like what Thiago put together. It would solve a long-standing issue for SVE and gdbserver and it seems simpler at this point, plus Thiago already put the effort to write the code. >> I can imagine a vector of registers whose size >> depends directly on the value of some other register that comes before, >> like: >> >> >> >> Here, "some_other_register" would be a scalar register that comes before >> "vec", and whose value dictates directly the number of elements of >> "vec". But if you wanted to say that the number of elements in "vec" is >> the value of some_other_register, times 2? I guess we could write: >> >> >> >> .. but then we get in the realm of defining a grammar, building a >> parser / evaluator, etc. > > We could rein complexity in by supporting only the simplest of > expressions, e.g. only a very rigid form such as “ > ” where is one of the basic arithmetic operations. > If that turns out to not be enough then we can increasingly support more > complex operations. > >> The type of the vector elements needs to be dynamic too, how do >> we define that? > > This is the part where I got stuck, especially on how to make GDB's type > system allow expressing such a type. > >> If the number of possibilities is known and static, we could have some >> kind of "variant" type, where we list all the possible types, and select >> among them at runtime based on the value of a preceding register. > > Yes, in the case of SVE it's known and static. The maximum vector length > is an architectural feature of the processor, and GDB/gdbserver can get > it via ptrace in the NT_ARM_SVE regset. And it's always a multiple of > 16. > SME is a bit more strict with the allowed vector lengths. It is always a power of 2 between 128 and 2048 bits inclusive. So in practice 128/256/512/1024/2048 bits. > It's an interesting idea. Perhaps it's enough, at least for SVE? > >> If I understand correctly, all of this makes it so the size of the >> response to the g packet will be dynamic too? > > We /could/ set the size of the g packet to always correspond to the > largest vector length possible but it would be a big overhead, > especially if there are many threads involved. Or we could use the opportunity to break free from the g/G packet restrictions and go for a more flexible format while at it. Given most of the fields contained in these big registers is 0 or same value, there is potential for quite a bit of compression. Just an idea, while we're throwing ideas out there. > > So in practice yes, it will be dynamic if we can help it. >