From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iBz0INEH4mMPFiwAWB0awg (envelope-from ) for ; Tue, 07 Feb 2023 03:12:01 -0500 Received: by simark.ca (Postfix, from userid 112) id 836E51E15D; Tue, 7 Feb 2023 03:12:01 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=UjRt6bmg; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1136B1E110 for ; Tue, 7 Feb 2023 03:12:01 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BCD3A3858D38 for ; Tue, 7 Feb 2023 08:11:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCD3A3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675757519; bh=AlrLThzO+3M+CBoACksqxC/a8bZ7H/bvQ7u3AngaZhg=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=UjRt6bmgF9NqqhrH8QW1gm/itkBcIwfSstj+fQGMwx9FBN3NJOGlN8s3shU9jeukD +Zy/TaCdQiZTj4rwm2rXz/+TnRodWN5/tvYOV2KJT4F8BOrIkCqoEgZFDv0+SUgWET l7bPQMBBGmQzyhsKcdqWVIE90+vIqqvSgcgRLtGk= Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2048.outbound.protection.outlook.com [40.107.21.48]) by sourceware.org (Postfix) with ESMTPS id 125283858D1E for ; Tue, 7 Feb 2023 08:11:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 125283858D1E Received: from DUZPR01CA0235.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b5::19) by VE1PR08MB5776.eurprd08.prod.outlook.com (2603:10a6:800:1ac::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.35; Tue, 7 Feb 2023 08:11:28 +0000 Received: from DBAEUR03FT053.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:4b5:cafe::85) by DUZPR01CA0235.outlook.office365.com (2603:10a6:10:4b5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.36 via Frontend Transport; Tue, 7 Feb 2023 08:11:28 +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 DBAEUR03FT053.mail.protection.outlook.com (100.127.142.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.32 via Frontend Transport; Tue, 7 Feb 2023 08:11:27 +0000 Received: ("Tessian outbound 43b0faad5a68:v132"); Tue, 07 Feb 2023 08:11:27 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e52cb587eae8b995 X-CR-MTA-TID: 64aa7808 Received: from a61c70bdede2.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C7FE82F3-A6EE-44BD-B882-F8916C6254A3.1; Tue, 07 Feb 2023 08:11:21 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a61c70bdede2.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Feb 2023 08:11:21 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hpU8tTi101WCgALJjsQ4jT9QxtfbYESLaeU1DZSCO6yPi0oITAX/WfYepJozF57+fV5KGwmDqtkhq5yPoxGhMl70/KiQCu12PoW3Bzf2VZpzICFtT137mvdjMy1wTNtAAIaGrekVezBwRNqn9CmfvIeTtgCfxw0YmhfRDqH4LgSPlYnF420SwQS6lf/VS5hU9Ovo4MBRDfrI34+xII17AJ99W8CmzRPc1vCebdEzis8TwPhc2lnZNYiKBgi/WqsBvrQJTFEgYvNE01Jd3UtWHz6m4YrJctdOL9JtbMY578fT0B8Dr9hDakoBDUEZtawtqVCp6Hfsmx6SKmUSWqT6MQ== 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=AlrLThzO+3M+CBoACksqxC/a8bZ7H/bvQ7u3AngaZhg=; b=KOb1uhUt/STXwBl/RXCJYLf8OXPxiQwf/RtfPksuOukZaaiGE4OUilhuTapU2AW5GmEz43PI43ZUGVZACfROvkYTKvWiRDdGAu96iKUFRG/NqO66wExlADCIoYhq43Jrq176op4sSnzJf4aok5Ipcfjw2FDbjX2OTNZMBVWb/+YZio60FFtif5pRGYwO5SpCqQrahPpiRdXkfr455J+bqbeLwCGBmpIsH1VNfuPad/566Tva6WPZXWqtqyxBq+L6qyXxyhG/XX4vRkiAatYnox6/ZmsjilCyzeUkBAZFI5g8X3RhkuNNJq6EMbTr8E/JU2UJXRn+/+tZ1sD+ud26TQ== 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 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 DB5PR08MB10096.eurprd08.prod.outlook.com (2603:10a6:10:4aa::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.29; Tue, 7 Feb 2023 08:11:18 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6%6]) with mapi id 15.20.6064.036; Tue, 7 Feb 2023 08:11:17 +0000 Message-ID: Date: Tue, 7 Feb 2023 08:11:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description Content-Language: en-US To: Pedro Alves , Thiago Jung Bauermann Cc: Simon Marchi , 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> <9d30751a-589b-eb95-09b1-61d083ad9730@arm.com> <87leldmp6r.fsf@linaro.org> <045c1e09-5b6d-22b6-df7a-39cfa339b0e1@palves.net> In-Reply-To: <045c1e09-5b6d-22b6-df7a-39cfa339b0e1@palves.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ad::14) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DB5PR08MB10096:EE_|DBAEUR03FT053:EE_|VE1PR08MB5776:EE_ X-MS-Office365-Filtering-Correlation-Id: 50e30e6a-7620-4fce-69f3-08db08e2e992 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: LS2/NNUJJwhepbz0FEs1Phz/BIF4BmCfK8xsKUR/mXGBhIFBBDujitcYpWNAU6I3sBEvwGr5qaY89hokzKO6swzJQKUNK67OL6NqykvZTn5Wri+u4jpyojWpBenwjsn0Dfs/9mWX+gvdNy+oca+/NP7BoztbZ4wuIQsUD+cCE3DVMCKS/He5cO/dhTuy1Ep4nzpmXYMK700ujkHvbOaqaxtK5Qu3yINcNjtbm4IYqDuuihU0agICUiGP7S/bwmtDR0xu4FpmuB19+cqp0PNNWVoj9b7ExRF2avozhCDETO6XloZyCoMAj1KryzNzjzBc4qhGkjsL9Ye8S4B9EJ1HnqFHGTlFcRk4GY2BUiEAvOWuqsxU/19lXYhY9Ml1iJ1qWpwpaVmdVDsKFuqjVWsqCRP4M2hVHmZKx5cHJrUB8o8MHh85Q5VKmJBA5l1eJCcqWDl23StXIGAluvlzc/Vh4V84EyuzMQlNUzCPtsYfShzCB2agWYXj8E4QVhT40ORf0FSpISRbEiwoo7x+eEpdrA/T0Om8fGCsst+OZh9InEALt5rmHYB+LjLAd6e8oEYXejMb+NCZzhAZE2d9sxY4kzd9s2GxT0Znn4xh2+JBi8L+WYSMdgUj7IPinJ0Ud3wpb+FOAtjEMaL3GHPmPNZH3VfJ7iEEiFSKMbO0hEOxRF/RKAV5y8U4fpVmD8DZtyIBcT0gObv5hRIsFARjzOKMa8kHIcrQaZephezUWWvUKcY= 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)(136003)(346002)(396003)(366004)(39860400002)(376002)(451199018)(316002)(54906003)(110136005)(66556008)(2906002)(5660300002)(36756003)(44832011)(66946007)(38100700002)(4326008)(66476007)(8936002)(31696002)(31686004)(8676002)(478600001)(2616005)(86362001)(6486002)(41300700001)(53546011)(26005)(6512007)(186003)(6506007)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10096 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: DBAEUR03FT053.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 080e9142-85f4-41e8-6f35-08db08e2e386 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MQLjA2PRJ0hawiQSSDE/cOM9PG8YgrF13iiVq7S3OaULdge+hzE2dTe4wVvu/jnyF7fSBUUz9wCCgBCjWFQDMcytUnV+PfwVEEYUX2WrQrxGe9o6RhjocH/kBv5BigGsxSD+09dM1ua7vlSnujYWhHzLi4zmNMo6o9CscFhCotwAdA1hx6I9IJ3kR/mnsaEg1r39KxA2v/84mxmBCwwbMPhL/H8lD2hAbTEIiOFa8+4+ZUkf7IslFP5qvmrVdl2bbbzaeL9OXH9rkTGO3XEyu9LJ7TTeiVm7P3K0DTG8kqGxiazHS+JDGWldVeMgrwz3xsXN8VpT4XOS9p8rwwHIs+ZHERNhvqOmopvYgvIu8Uo1vLLwNu2bEOnmGJFrQnDclCE0SQ2/obLKwHTTS93qtg0Q+fhCz7uS890JFwwuyr4npdjzYeTK14fU5htHkdLe5Wq9HUjYEQu6J+ow3i9RkWwEjYgEpu92bl7gpfExWf/l2tgr0eRCnLaw86WRB+s7z+8oTpzX7uY2ciZi8BMBwZm7ByUI3L355gTBiKqW/hR193v3OBlmDaStiYxM2mrwE89SyBsKSzoX6T7lq/BIR8aSKqKS6Cb9+gTkAHe0pRQOOSW3XA5obky6/kGpC78w3fzFtO+skSod8XlKYUE4Lp4CX4TJvJQl0SsD7u51A+seI8LXUnryhL3VybsXizRMUW7HAm4tcktNmMUsur8Epc/zLjJto7U0QQoKl6NY11o= 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)(376002)(346002)(396003)(39860400002)(136003)(451199018)(40470700004)(36840700001)(46966006)(186003)(6506007)(316002)(53546011)(82740400003)(8676002)(26005)(86362001)(2906002)(6512007)(2616005)(70586007)(70206006)(4326008)(356005)(81166007)(5660300002)(8936002)(41300700001)(40480700001)(44832011)(36860700001)(336012)(36756003)(47076005)(82310400005)(31696002)(40460700003)(110136005)(31686004)(54906003)(478600001)(6486002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2023 08:11:27.7218 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 50e30e6a-7620-4fce-69f3-08db08e2e992 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: DBAEUR03FT053.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5776 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2/6/23 20:29, Pedro Alves wrote: > On 2023-02-04 3:21 p.m., Thiago Jung Bauermann via Gdb-patches wrote: >> >> Luis Machado writes: >> >>> On 2/2/23 03:47, Simon Marchi wrote: >>>> On 2/1/23 21:54, Thiago Jung Bauermann wrote: >>>>> In any case, it wouldn't be possible to make get_thread_target_desc just >>>>> return thread_info->tdesc because at least the way these patches are >>>>> currently written, when the inferior starts or a new thread of the >>>>> inferior is spawned thread_info->tdesc is nullptr. gdbserver will only >>>>> call get_thread_tdesc after the first stop (in get_thread_regcache, in >>>>> the process of obtaining the pc register), so we will need to cope with >>>>> that situation. >>>> Ok. Would it work if a new thread initially inherited the tdesc from >>>> its process? >>>> >>> >>> It should be fine because the first time we fetch a process target >>> description, it is eventually obtained from the first and only thread. >>> So the SVE vector length should be correct. >>> >>> Any subsequent attempts to use the process' target description (the >>> first one we obtained), after further stops, may end up using an >>> incorrect description. >>> >>> I think this is handled correctly by the target architecture target >>> hook though. But there are other places where this is potentially >>> incorrect. >>> >>> For example... >>> >>> - When using gcore to dump a core file, GDB only dumps a single target >>> description. While this might be correct for a target with a fixed >>> target description or a AArch64 target that doesn't support SVE, it >>> likely won't be correctly for one AArch64 target supporting SVE if its >>> threads changed vector length mid-execution. Either we emit target >>> description notes by thread, or we don't emit a target description >>> note for those cases. >>> >>> - When loading the above/older gcore core files back, GDB will use a >>> potentially incorrect target description. If we decide to emit >>> per-thread target descriptions, it should be fine. Otherwise we may >>> need to have a "thread architecture" hook for core files as well. >>> >>> - The remote has no concept of a thread architecture (Thiago is >>> addressing this with this patch series). >>> >>> - AArch64 frames may have slightly different vg values, which means >>> their gdbarches are different as well. >>> >>> Given the differences between two gdbarches are small, we mostly get >>> away with it. But if there are further differences (different hooks, >>> for example), I fear we may run into a situation where we use an >>> incorrect gdbarch to call a particular hook. >> >> Indeed, good points! Thank you for bringing them up. I can address core >> file dumping/loading after this series. >> >> Regarding frames with different vg values, it's important to be aware of >> this discrepancy but IMHO it makes sense to work on it when it becomes >> a problem... >> > > > Yeah, one thought that keeps crossing my mind is if really modeling all this > stuff as different target descriptions is really the best approach. The Intel AMX > support posted on the list last year also ran into a similar problem, with the > matrix registers height/width changing at runtime, and it is impractical (or really, > it really smells like the wrong approach) to have different target descriptions for > every potential matrix size. Which is not unlike different SVE sizes. It feels like > a single tdesc should be able to be a bit more dynamic. It's a bit funny that ptrace > manages to work with a single registers interface, while we don't. My understanding is that this was a bit hard to justify back when SVE was implemented, as it would have to touch some other bits of the type system to create a sizeless type for SVE vectors, where the size would be determined by context. > > What if we extended the target description mechanism so that a single description > could describe all SVE sizes? For example, what if a tdesc could describe the SVE > width/length as a dynamic property, retrieved from elsewhere, e.g., from another register? > > BTW, for core files, where are we going to retrieve the SVE length from? The thread-specific vector length should be available from the SVE register dump sections.