From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oED0ERGdAmZZrxYAWB0awg (envelope-from ) for ; Tue, 26 Mar 2024 06:01:53 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.a=rsa-sha256 header.s=selector2-armh-onmicrosoft-com header.b=odHSqhq1; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.a=rsa-sha256 header.s=selector2-armh-onmicrosoft-com header.b=odHSqhq1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4191C1E0C0; Tue, 26 Mar 2024 06:01:53 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 117EA1E030 for ; Tue, 26 Mar 2024 06:01:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 90118385828E for ; Tue, 26 Mar 2024 10:01:50 +0000 (GMT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2055.outbound.protection.outlook.com [40.107.8.55]) by sourceware.org (Postfix) with ESMTPS id 4D729385840A for ; Tue, 26 Mar 2024 10:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D729385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4D729385840A Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.8.55 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1711447288; cv=pass; b=rYohLYKyGn1Yu34s+PNLSk9zSyjl8G5t0yqi7AtHw+bI+j2IJG7MfoEpKzgeKhZ48ob+xsa9rEy8iDwp6diRen9aJHo+XjqD8VmEYP79EEyNFh9o7YJDmtE9BL57u4qYyl+cjYgJ30G1f2JyChIErxeCq+cKfxGG/flplM48j8o= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1711447288; c=relaxed/simple; bh=5zJZ3Gv1FSf0l2X9cUsYESwLuJ82fSoQqOXehE0jwBs=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=m3xsY/flu0Z+Ddo+teNx23gqReHG37q5sNvaz3nvCAFsOLnet+Nz+rYeMgT2UXDRYWdxGdahcxeOunF5Qwf2ctakDXt3GFeLvHVdOh1p2S4X2//huKFtmrfauu+HiXXR2639KNN77sac56sraExEGZvXvTKrdJ2uRrcpbVlUtUQ= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=dVEK8Ibt//SsWoKx24r3+9N/AjirgnEFxqPH69lHD3cUPhclp3MguQNkNIlnXWyzs8wb9I6TzL2A52TE6EwDsRtyKQW27MrtNRpYDzWz9NIAnJXsfhWs8TJuWd2DdXX/e8liLI0fwbJXknh3RYWeLF43d0o9mq1u3HD70TVBr678v0RXrVzXUklu7hdjLp7j/NtuR3Klm2JVBiTe6l3PagbJTrd6ojRgough6SrlEM4Tv/QpXE5yqdrhwm6KsW0XEZ2+Ts+4CEiTeNJERxt6yjCBtKgamGNNzMHa65hBjRLRynlM/4nchpBRwZ/vow4536PRuJKzB23Ke0Y21dvIMQ== ARC-Message-Signature: i=2; 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=c+Ri/b8BmNj+hfpvTywsl/brZZmH8M7HtrLpep/fNs0=; b=XcKE8ILXuVVOqSli074Xie7RP68C0Xl5myaddRP65HeVtdiLodpSuaXtT44lAS8mW9TVkvfucmFCVpd75Hvlzm5GbeJgUhSlH3PgPDHMDT511zxfSiUEkM4I84Cqgxa3dWvetPr+hSRuKs8l38VX+PMKkJpg1CWhM0d9aacoENK/B4ppcMdtKapc3jE62ML+b4mDaubaniM07PdltPcfpOwc0hCGglKc67nStUdtl959TGb2SiOPnYPUlnTptSTYAbUMsmJlOKiCzPBdeB/02r1QDbH7Zh5PgAcYWRnk/rNrqszmaHAOKU5z8qQzJg0WEPLJo9yOY7w1Ou8i3sFMtA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=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=c+Ri/b8BmNj+hfpvTywsl/brZZmH8M7HtrLpep/fNs0=; b=odHSqhq1zLSb/lbP5kCyEmZzsz3sgnbluefBUjOlwzae217qFx7yCgqzjW2J+4xxMPcBZPedSWpdRsvBjDxn7TzKqNuHi2N0dWzfHA9KQzo9xbkxmj/Winq+mstqyb/SugGSz29jUI7Fiap17mJk/i/tgJcE7Zi2qFjUpNSL7Pw= Received: from AM6PR0502CA0054.eurprd05.prod.outlook.com (2603:10a6:20b:56::31) by DBBPR08MB10461.eurprd08.prod.outlook.com (2603:10a6:10:535::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Tue, 26 Mar 2024 10:01:14 +0000 Received: from AM3PEPF0000A793.eurprd04.prod.outlook.com (2603:10a6:20b:56:cafe::46) by AM6PR0502CA0054.outlook.office365.com (2603:10a6:20b:56::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.13 via Frontend Transport; Tue, 26 Mar 2024 10:01: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 AM3PEPF0000A793.mail.protection.outlook.com (10.167.16.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.10 via Frontend Transport; Tue, 26 Mar 2024 10:01:14 +0000 Received: ("Tessian outbound ff4e98f65004:v300"); Tue, 26 Mar 2024 10:01:14 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ee5ac23dda5a2b62 X-CR-MTA-TID: 64aa7808 Received: from b00b71b3ed3b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2833AA55-AB3B-43D1-89F3-CF1982FC5000.1; Tue, 26 Mar 2024 10:01:07 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b00b71b3ed3b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 26 Mar 2024 10:01:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jTJIxFp7utOdqJVjpvq98voId93b9Hmo70Q16iQ+ityYOxzu6XFMq6q6/M6i/tG+vbHBWuDemzlidt3VhLLC/f5mVu3go4ybTOBKk7lAd5tGhWS+RqklK9V9idVoDxTit6bRZDgTpdgiREH5EFKsr4ThiKQAcK2YdqwKYQ/JXrQQlAFXTRKhNwy86ojmAo0NPs6DB8of+ocIOom9KA5aMeyepzwOkNDb/xRbnfpQijp7G9nHF17RLGU1ITWDc+dbblCp+2edBbQuPM9CsqdRcHFKbhjorgDvsy3oMi2sKsu3SrZPpsGQ7QYHHO1ebv6WkXqCzBFywcYcglaasTlHpA== 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=c+Ri/b8BmNj+hfpvTywsl/brZZmH8M7HtrLpep/fNs0=; b=P7eSrUfGRnDasm2frufac4NwnhQx3/PyX6U2Cvn/JjCGUIx9gXsORG+iVT21jaCKHdcYbSsfIj6Ue9XiD14MJhT8PBACoYw8xgPnpwyLx+jjg82uE55SchjI0/tlLSGe3Y0jJGMkbI0OhcB/0pjLExh3RGXs10vYEiTUMKxWpGveIm+pmPsCzXKszL4KKTH87y+6d1Vc6qB485Ebpa3SP1ZqVOvnj/nuHWyfVaVwDTx1Kg6vgd0LFR7jkh9vslSrAEq9vye+M6ihqkxJ257ee1HkMItskVIEeD++HgnxPJklZhjnx/Cr/BN6jL+7QVjeouKBYecOrxQdyEQ8bYkg8w== 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=c+Ri/b8BmNj+hfpvTywsl/brZZmH8M7HtrLpep/fNs0=; b=odHSqhq1zLSb/lbP5kCyEmZzsz3sgnbluefBUjOlwzae217qFx7yCgqzjW2J+4xxMPcBZPedSWpdRsvBjDxn7TzKqNuHi2N0dWzfHA9KQzo9xbkxmj/Winq+mstqyb/SugGSz29jUI7Fiap17mJk/i/tgJcE7Zi2qFjUpNSL7Pw= Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by DBAPR08MB5749.eurprd08.prod.outlook.com (2603:10a6:10:1af::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Tue, 26 Mar 2024 10:01:02 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::363f:3fc8:fc36:58ed]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::363f:3fc8:fc36:58ed%5]) with mapi id 15.20.7409.031; Tue, 26 Mar 2024 10:01:02 +0000 Message-ID: Date: Tue, 26 Mar 2024 10:01:00 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv2 6/7] gdbserver: update target description creation for x86/linux Content-Language: en-US To: John Baldwin , Andrew Burgess , gdb-patches@sourceware.org References: <87plvqt6jl.fsf@redhat.com> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0129.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::21) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DBAPR08MB5749:EE_|AM3PEPF0000A793:EE_|DBBPR08MB10461:EE_ 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: AqI577usYlyUJFO6nlkRBJ3FPw4VY+lYbzUTmt7zORfRpfNEoguwggtSeAGACOU1HQ2bfD2eVmfTjBHGm+7YB5cBwMqRRznYoUSRIq5icB2pbeFOIEnAambOWvFE38e1gSuJ/tbOY97iqyF82zq+FPq2O3v//vWdL0SJE5StaOYq6Xlm/aDSh+qv2dH9M/O76TBaPDAYqTwyEyBd1NrWqiSmsgQDj2e6CkQlgMfG7jokjeKvx6qcrvp9MF1IDPdCnEV3r9JS9uPjgiyGlR4+b46AcL0gotncMIrY4p19P8CY85YjjcyYZSPk1bpP6CVFAM7n8FhsOW4PAZMXmSouP/kUdM75qAsRaIiNg77Ilj8gIC8SoyclxOI/KTxH2SuaXiZmo6/FxIl4/i+NDHTJSSPbTOB7YohHJ4nfLqyShbldPv1NEjwbbYSDYYrMmMsuogICWPszQQl9S8R4nEqvBdZEWnCqLPp6VP6Um+tdri0oEwzsevvjhby2/MtAB0QpVufin3CGDutTkw434iHXSHriP3eE6Vr9WrxP9grtsSlbuSW+fRfuffjYFfefa04yfYB6Jvwf6ph+pCfmSbVz7YZBPf5uS2UN+uxB4PMbdMwQ+f4N/ktXlRW1Xz0Maw6S9LZ82FeDOYppI+qGvTWiBLU2BaZyPuCqIuuq6gX5BC4= 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:(13230031)(1800799015)(376005)(366007); DIR:OUT; SFP:1102; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5749 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM3PEPF0000A793.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 652b3be8-de2f-4702-477b-08dc4d7bac4c X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: H3azZiBcfFGCGQw7DMmYj034yTAVytufYgGEVPl9NHSITw1TpRQmrjgTkG9zQ/4CWvkORBja7Cp1Tu3VwOQDSowfJ9+3Ig9/H2X6QNqCztWzbKSzicb1oG5ETsH80NWxIPpFvR9KT7y/lbrZz2uQGhnGaratvArTrcw9LH2McqV4u7PtnddQakT9LmMdSrtpvtwO/0ycOiq+p8swiEKemBtD0b6tfVShUT1OgTHXPnJWMw9c7Wv+/32Izvd9rgXiIr70LkUsyNkehOmwgbZS6g/2DE+REqpuxYUK6v+AbfD8ViD4rXE0fiPjzE3QPssZADmmQBcbvvpQC3mmZqP6pHbsp0qi2KabkEZnEssjsuwcjJ/q62p2fIm+tKqstpVjutjkTNwBITYIhe5Xe/cqP1Fce6M3Vd7UtZelXzdGv/G5/9kDpxItTXa0eNpQTKTfmCj8nLEV6kxXu6tm+/aXKgelLQn0tgS2Nzy8qpCrVgdy4Nb6g5yZA02jyjNMFs0xmIdywSvqPyEHcCppDRQSOfTaogFPtBDXuDP3QSRA33CE4eY3tE3wFwTSVbQA/v1M9l/a8Yl75fH4Tlag+tlGCZGUtD0BquZ2annP6mE9FdJq9Jehx+pvNEKHERGRA1KlO688tpic95YMzNUmD9lrEtcohKMzlpv8+ZZOQgQfjIw8WFrCpGN1WxfTDzjHK1KiA5U7e28eOdyoTMm4l42tzq7w3msSzrg5Ydb0wtVg8eb6a4HOWCEhr6cc6l4VkL1q 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:(13230031)(376005)(1800799015)(36860700004)(82310400014); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2024 10:01:14.5357 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 652b3be8-de2f-4702-477b-08dc4d7bac4c 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: AM3PEPF0000A793.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10461 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, KAM_DMARC_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org On 3/21/24 17:28, John Baldwin wrote: > On 3/19/24 11:34 AM, Andrew Burgess wrote: >> John Baldwin writes: >> >>> On 3/5/24 9:00 AM, Andrew Burgess wrote: >>>> This commit is part of a series which aims to share more of the target >>>> description creation between GDB and gdbserver for x86/Linux. >>>> >>>> After some refactoring, the previous commit actually started to share >>>> some code, we added the shared x86_linux_tdesc_for_tid function into >>>> nat/x86-linux-tdesc.c.  However, this function still relies on >>>> amd64_linux_read_description and i386_linux_read_description which are >>>> implemented separately for both gdbserver and GDB.  Given that at >>>> their core, all these functions to is: >>>> >>>>     1. take an xcr0 value as input, >>>>     2. mask out some feature bits, >>>>     3. look for a cached pre-generated target description and return it >>>>        if found, >>>>     4. if no cached target description is found then call either >>>>        amd64_create_target_description or >>>>        i386_create_target_description to create a new target >>>>        description, which is then added to the cache.  Return the newly >>>>        created target description. >>>> >>>> The inner functions amd64_create_target_description and >>>> i386_create_target_description are already shared between GDB and >>>> gdbserver (in the gdb/arch/ directory), so the only thing that >>>> the *_read_description functions really do is add the caching layer, >>>> and it feels like this really could be shared. >>>> >>>> However, we have a small problem. >>>> >>>> On the GDB side we create target descriptions using a different set of >>>> cpu features than on the gdbserver side!  This means that for the >>>> exact same target, we might get a different target description when >>>> using native GDB vs using gdbserver.  This surely feels like a >>>> mistake, I would expect to get the same target description on each. >>>> >>>> The table below shows the number of possible different target >>>> descriptions that we can create on the GDB side vs on the gdbserver >>>> side for each target type: >>>> >>>>           | GDB | gdbserver >>>>     ------|-----|---------- >>>>     i386  | 64  | 7 >>>>     amd64 | 32  | 7 >>>>     x32   | 16  | 7 >>>> >>>> So in theory, all I want to do is move the GDB version >>>> of *_read_description into the nat/ directory and have gdbserver use >>>> that, then both GDB and gdbserver would be able to create any of the >>>> possible target descriptions. >>>> >>>> Unfortunately it's a little more complex than that due to the in >>>> process agent (IPA). >>>> >>>> When the IPA is in use, gdbserver sends a target description index to >>>> the IPA, and the IPA uses this to find the correct target description >>>> to use. >>>> >>>> ** START OF AN ASIDE ** >>>> >>>> Back in the day I suspect this approach made perfect sense.  However >>>> since this commit: >>>> >>>>     commit a8806230241d201f808d856eaae4d44088117b0c >>>>     Date:   Thu Dec 7 17:07:01 2017 +0000 >>>> >>>>         Initialize target description early in IPA >>>> >>>> I think passing the index is now more trouble than its worth. >>>> >>>> We used to pass the index, and then use that index to lookup which >>>> target description to instantiate and use.  However, the above commit >>>> fixed an issue where we can't call malloc() within (certain parts of) >>>> the IPA (apparently), so instead we now pre-compute _every_ possible >>>> target description within the IPA.  The index is now only used to >>>> lookup which of the (many) pre-computed target descriptions to use. >>>> >>>> It would (I think) have been easier all around if the IPA just >>>> self-inspected, figured out its own xcr0 value, and used that to >>>> create the one target description that is required.  So long as the >>>> xcr0 to target description code is shared (at compile time) with >>>> gdbserver, then we can be sure that the IPA will derive the same >>>> target description as gdbserver, and we would avoid all this index >>>> passing business, which has made this commit so very, very painful. >>>> >>>> ** END OF AN ASIDE ** >>>> >>>> Currently then for x86/linux, gdbserver sends a number between 0 and 7 >>>> to the IPA, and the IPA uses this to create a target description. >>>> >>>> However, I am proposing that gdbserver should now create one of (up >>>> to) 64 different target descriptions for i386, so this 0 to 7 index >>>> isn't going to be good enough any more (amd64 and x32 have slightly >>>> fewer possible target descriptions, but still more than 8, so the >>>> problem is the same). >>>> >>>> For a while I wondered if I was going to have to try and find some >>>> backward compatible solution for this mess.  But after seeing how >>>> lightly the IPA is actually documented, I wonder if it is not the case >>>> that there is a tight coupling between a version of gdbserver and a >>>> version of the IPA?  At least I'm hoping so. >>>> >>>> In this commit I have thrown out the old IPA target description index >>>> numbering scheme, and switched to a completely new numbering scheme. >>>> Instead of the index that is passed being arbitrary, the index is >>>> instead calculated from the set of cpu features that are present on >>>> the target.  Within the IPA we can then reverse this logic to recreate >>>> the xcr0 value based on the index, and from the xcr0 value we can >>>> create the correct target description. >>>> >>>> With the gdbserver to IPA numbering scheme issue resolved I have then >>>> update the gdbserver versions of amd64_linux_read_description and >>>> i386_linux_read_description so that they create target descriptions >>>> using the same set of cpu features as GDB itself. >>>> >>>> After this gdbserver should now always come up with the same target >>>> description as GDB does on any x86/Linux target. >>>> >>>> This commit does not introduce any new code sharing between GDB and >>>> gdbserver as previous commits in this series does.  Instead this >>>> commit is all about bringing GDB and gdbserver into alignment >>>> functionally so that the next commit can merge the GDB and gdbserver >>>> versions of these functions. >>> >>> It does seem like the IPA case should just compute the tdesc it needs >>> if I understand you correctly. >> >> Yes, totally.  And it's not like it would even add much code to the IPA, >> I believe it already pulls in all of the target description creation >> code, the only thing that is "saved" is the code that probes the >> hardware to figure out which description we should use. >> >> This whole area seems like it has not aged well :-/ >> >>> >>> BTW, on other arches like aarch64 and I believe risc-v, a flat array >>> is not used for the tdesc cache.  Now the cache is a std::unordered_map<> >>> and there is a 'struct foo_features' that has an operator== and >>> std::hash<> specialization.  It really would be nice if x86 was the same, >>> but that would require abandoning a notion of a portable "index" shared >>> between gdbserver and the IPA. >> >> Indeed.  I did the worked on the feature/hash/lookup for RISC-V so I had >> this in mind when looking at this code.  Originally I had planned to >> switch to a map style cache, but when I found the IPA/index passing code >> I lost my nerve and tried to find a solution that was inline with what >> we had currently. >> >> I don't really know about the IPA enough to make claims about what >> is/isn't a reasonable change in this area. > > I have zero knowledge about the IPA myself.  OTOH, if no one else steps > up with a strong opinion here, I would suggest that you go ahead and > fix the IPA as you described so it is more self-contained and then we can > use a saner approach for dealing with tdesc caching for x86. > Should we start thinking of deprecating the IPA if no one shows any interest in keeping it alive? It is there to provide support for (fast/static) tracepoints, and I haven't seen anyone using it in the open for years now. The cost of maintenance may not justify keeping it alive.