From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on2087.outbound.protection.outlook.com [40.107.13.87]) by sourceware.org (Postfix) with ESMTPS id DEA003858D20 for ; Fri, 3 Feb 2023 11:14:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DEA003858D20 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=8NGSsHT5z7DJwxiuntCwe9cZ1kms97LVGMkxXrni0MU=; b=P9P7bt5FsNYnZx/u/JPBCKXpDSsYkFo4UsCS5+OxPMfRwuUHz0U5kzgjnQiIsTvhi4UHeBtagf53qDECOs817FRU3T3y8WXo0ZDi7rTKt2B71tOZZ8o16YqPDaRLPU72sCThCNSz+qpVJh2bpdTAMD97tDQqdFSWLOylE4VKmKg= Received: from DBBPR09CA0012.eurprd09.prod.outlook.com (2603:10a6:10:c0::24) by VE1PR08MB5711.eurprd08.prod.outlook.com (2603:10a6:800:1ae::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.25; Fri, 3 Feb 2023 11:14:03 +0000 Received: from DBAEUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:c0:cafe::98) by DBBPR09CA0012.outlook.office365.com (2603:10a6:10:c0::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.29 via Frontend Transport; Fri, 3 Feb 2023 11:14:03 +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 DBAEUR03FT060.mail.protection.outlook.com (100.127.142.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.28 via Frontend Transport; Fri, 3 Feb 2023 11:14:03 +0000 Received: ("Tessian outbound 6e565e48ed4a:v132"); Fri, 03 Feb 2023 11:14:03 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 6e81c32a74a41907 X-CR-MTA-TID: 64aa7808 Received: from 81f5a1e671a1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8777C646-CA4F-4AEF-A8F8-5557421680BF.1; Fri, 03 Feb 2023 11:13:56 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 81f5a1e671a1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Feb 2023 11:13:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LzKx8gPCrECbkqx8d1RFtBl85lT+du+KOqUDEZBvmuBp3yMy81CAcpXYZcp/yvxUtdnOJ5pUB49ZtKLe+81WnMj1jHYj096r+19R1AhIQ753gK5Tn/bBGQrCVYPjwR0dbSHyBNQQfIgJP4j1bFqFLFXZxBhqtjDOez0lua2d6NYtUy8i/lhUaYNm7yiU+xnwb5WJDXyc6FR/XUaYSvQiG5zcJVlvEMxmIj57q0ax/EGBc+IeV5VMbvIunykZ3gtNln5hrb2rV1dWUVzxJKLSzyCR8HR9C5/hlMLi/rBROHoIzZGZ2GqRZFtLO9xMMldEXcLWtO4cGc52voirDMlkhw== 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=8NGSsHT5z7DJwxiuntCwe9cZ1kms97LVGMkxXrni0MU=; b=QkKBvME4obDZLBdEhYYusGHJY+x9EdE7whY5CyiAEF3Ddbalh2qGnrq3VXwCaR5CbYCHBfHTk/0aMBLc+4fk/LnkPFl062ierWKhybwvirGwi87E9K7malFI5rOwL9xT9Bs0w/gq1zbQikR77hyHgZCZ1qjr8JTQgd4S2Cj/vY7NhJA6fXi3yiDo/gnMzysd89MxOGd5MZfla1jtxJtPsjiZcmRjXZim2PDu/otmwtv/9T05M1rvnGY3MJRJYOuDaSLDHY61pLF0kHTQtXDnL8zwidzY8XUka5TyL7iZk2Wb3ym5bo67huZFYmHYZGN+93VMI4VGg60cMqE1aw8PVg== 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=8NGSsHT5z7DJwxiuntCwe9cZ1kms97LVGMkxXrni0MU=; b=P9P7bt5FsNYnZx/u/JPBCKXpDSsYkFo4UsCS5+OxPMfRwuUHz0U5kzgjnQiIsTvhi4UHeBtagf53qDECOs817FRU3T3y8WXo0ZDi7rTKt2B71tOZZ8o16YqPDaRLPU72sCThCNSz+qpVJh2bpdTAMD97tDQqdFSWLOylE4VKmKg= 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 AS1PR08MB7402.eurprd08.prod.outlook.com (2603:10a6:20b:4c6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.25; Fri, 3 Feb 2023 11:13:55 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6%3]) with mapi id 15.20.6064.028; Fri, 3 Feb 2023 11:13:55 +0000 Message-ID: Date: Fri, 3 Feb 2023 11:13:53 +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: Thiago Jung Bauermann , Simon Marchi Cc: 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> <871qn79zqk.fsf@linaro.org> From: Luis Machado In-Reply-To: <871qn79zqk.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P265CA0025.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ff::18) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS1PR08MB7402:EE_|DBAEUR03FT060:EE_|VE1PR08MB5711:EE_ X-MS-Office365-Filtering-Correlation-Id: c3fbf398-7496-4199-2f75-08db05d7c215 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: OeRQJ/NXamEHRZsJZBx7b63bUKBhvJJ699Ez+p3YLq3iYxwilEkv5WZ5EqT3dn69ULgCaMZbwKDjxkm1uFBiXZIqa51mfiDvf5mupAb6cu3P26NF90iGMW4K7i1GSQi7w0P0FFbRpmzC3ScIfzscxjf5u9RtQEK+FZtyfBhN28D39riRz3oKtQX4VIBYHalxlbFU7CNUFq5fgeca91suQbAKtwr0erPq0weG4RxlPnZF7DI6rH113BPGt58DI/G1QWblcUZ6i+IPvmkBXaGMHJhiOCoOcj+P/7+Oq7BMmxU0byo9//agLKO808lIwPnlKNsg5gdU9AEO/Winiz5oVL39nQ19xwVvXErw2v2/Zm8Lr/R7OajvH6oQLeAPU4dSk40b2RnvEN80ma+RxDF7M3ZTx6MgCQGGHCn7b2MRXqXGc4c5Io5uEt7STZloQtY/DIAr+3iLEceBD8oWKMJnrHWOWEOdvhlXM1m2ourHAvw5Gk02XBPV9Vo+0sr53kQb6GfrI+BtuNHKyEs4q8o/40U+SXQCNRk44MajhoDuqSbSNPNV/NZTC0o0F/SEMsQWaYhLwh7QxQMM1GSDS+h4SM3Xrt8y7M2o0zOllkm2lYAQNISj3fOhvKBicJado1D/AQi0N2bE/zH8gfh9uArBf7wI2kAjuT7Qs7T6A2fDCCoKVJH2amTZoXmfxzlsmFySbuf6lvUGcrHS/eX5S5syXya6XTrPzUOmUar8L2mtLmg= 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)(366004)(396003)(39860400002)(136003)(376002)(346002)(451199018)(2616005)(44832011)(31686004)(6512007)(186003)(26005)(6506007)(4326008)(53546011)(5660300002)(83380400001)(8936002)(6486002)(54906003)(110136005)(478600001)(41300700001)(2906002)(38100700002)(86362001)(316002)(36756003)(66556008)(8676002)(66946007)(66476007)(31696002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR08MB7402 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: DBAEUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 962b7909-3b6f-49a3-baec-08db05d7bcc6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iZ3TIWTwUK+ThVWmcFX5YyjVtGI5SdhdD6RAzfIsV1VnDpkGuOUVI1tiQ37EmtBdLLkc/8k7YeJwp2gjGf68gFTgEX/7Io84Kb3RC24uidZBXRjnOvi7vzNMXVatTayYyms0Xu186f1niMrsHKI6Y8WCxPLs8W6fvhnxgl6UUridxH/l6UdUWGhHKptOf2obSA0NQMBIS2azUkQQNX1O56Usfnxip+Z1DDAGcL/BOM51zh6hzeFl2A2dPHRrx/kDXxf1heJnd0D2zaYw1G9vVU8Bs44DqAGVHoJMBhEV6ZtQMNvmxpSGM/fq2vgP9Yn1kLzxEbWZAr6hAI6Yy8bXCfMp7l4knz/akw7i4+v/DBlNUAcZ5d3WzWLsc25LnZ8GeQVytIZltfdasyzbMwulLRAZtQM0DUA/3mDKmSos32a4VxSJ3tUHzcBBNwhoinG3cXMeWmUjLvmxQNjc2NPuYSkUaeCy+7Nb7k/+mZw9nivOD1bCkGvHLAd8FVzx5vfDkutO2LKSwPFafNok62Uu45yxDZxP6/+XsoHnYcL7eLRzEiV7uYWiTbjXCrewdj8rTxK6n3ABvKJKV8Yk2xbmoRv8AHn6c+rmDjPAOPJOR2cL1m14q0gGD9iMnidF3XWL/R1ANeWZedbqtNTJfoOV+DpHA0y95Ggpq2ONZVkdJfnt+zIzsz+ghGfG5AZINBoF4p2zYJ4eWNnnj0mQlfylHHbrjQY1dEKVoZHWQGwbVNE= 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)(136003)(376002)(346002)(396003)(39860400002)(451199018)(46966006)(36840700001)(40470700004)(54906003)(110136005)(47076005)(316002)(2906002)(82740400003)(81166007)(40480700001)(36860700001)(36756003)(44832011)(86362001)(31696002)(83380400001)(82310400005)(70586007)(356005)(70206006)(4326008)(8676002)(40460700003)(8936002)(5660300002)(478600001)(2616005)(6486002)(26005)(6506007)(41300700001)(53546011)(31686004)(336012)(6512007)(186003)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2023 11:14:03.5332 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c3fbf398-7496-4199-2f75-08db05d7c215 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: DBAEUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5711 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=ham 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/3/23 03:47, Thiago Jung Bauermann wrote: > > Simon Marchi writes: > >> On 2/1/23 21:54, Thiago Jung Bauermann wrote: >>> >>> Luis Machado writes: >>> >>>> On 2/1/23 16:21, Simon Marchi wrote: >>>>> >>>>>>> diff --git a/gdbserver/linux-low.h b/gdbserver/linux-low.h >>>>>>> index 221de85aa2ee..b52eb23cc444 100644 >>>>>>> --- a/gdbserver/linux-low.h >>>>>>> +++ b/gdbserver/linux-low.h >>>>>>> @@ -604,6 +604,12 @@ class linux_process_target : public process_stratum_target >>>>>>> /* Architecture-specific setup for the current thread. */ >>>>>>> virtual void low_arch_setup () = 0; >>>>>>> + /* Allows arch-specific code to set the thread's target description when the >>>>>>> + inferior stops. Returns nullptr if no thread-specific target description >>>>>>> + is necessary. */ >>>>>>> + virtual const struct target_desc * >>>>>>> + get_thread_tdesc (const thread_info *thread); >>>>>> >>>>>> I think the comment for this function is not correct. The function does >>>>>> not SET the thread's target description, but just GETS a target >>>>>> description suitable for `thread`. It's the caller's job to do the >>>>>> setting. >>>>> This comment also gave me pause. How does a getter set something. I >>>>> then understood that it allowed the arch-specific code to provide a >>>>> thread-specific tdesc. I would suggest just: >>>> >>>> FWIW, I read it as "the functions *allows* arch-specific code to set". >>>> So it doesn't set on its own, but it does allow something else to do >>>> it. >>> >>> Yes, that's what was in my mind when I wrote the comment. But I agree >>> it's unclear, and I adopted Simon's suggested version. >>> >>>>> The other thought I had while re-reading the patch is why do we need to >>>>> return and store nullptr if the thread target description is the same as >>>>> the main one for the process. get_thread_tdesc could just return >>>>> process_info->tdesc if we don't need a separate tdesc, and we would >>>>> store that same pointer in thread_info->tdesc. >>> >>> We don't need to return and store nullptr if the thread target >>> description is the same as the main one for the process. Things will >>> work fine if we do as you suggest. IIRC my private branch worked liked >>> that for a while, before I changed it to the current version. >>> >>> I changed it because I thought it was a clearer mental model if >>> thread_info->tdesc is nullptr when there's not thread-specific target >>> description. I can make the get_thread_tdesc method always return a >>> valid target description if you think it's better that way. >> >> Either way works. > > Ok, if there's no preference I suggest leaving it as it is now (unless > we decide moving away from process_info->tdesc). > >>>>> And get_thread_tdesc would just return that (in fact, >>>>> get_thread_tdesc might not be necessary then). Perhaps it makes some >>>>> things more complicated down the road, but I can't think of anything. >>> >>> Sorry, I don't understand this part. get_thread_tdesc is necessary >>> because it's the hook that allows arch-specific code to provide a target >>> description for the thread. I don't see how it can become unnecessary. >>> >>> Perhaps you mean the get_thread_target_desc function? Sorry about the >>> names being so similar, I spent some time trying to think of a better >>> name for either the method or the function but failed. >> >> Err yeah, I meant the free function that returns the process' tdesc if >> the thread doesn't have one. >> >>> 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? > > Yes, it would. Version 1 of these patches didn't work exactly like that > because I removed process_info->tdesc, but the new thread inherited from > the parent thread's tdesc. This happened in > linux_process_target::handle_extended_wait where the clone and fork > events are handled. > >>>> Sounds reasonable. >>>> >>>> Moving towards thread-specific target descriptions/gdbarch would be a positive thing >>>> given >>>> the SVE precedent. The process-wide target description/gdbarch no >>>> longer reflects the correct settings for each thread on AArch64's with SVE support. >>> >>> In the first version of these patches I removed the process-wide target >>> description and moved it to thread_info, but it was a big patch that >>> touched many targets. I can bring it back if you think it's worth it. >> >> At least for the register description, if we decide it's now a >> per-thread thing, what does it mean to have a process-wide description >> anyway? I think it would make sense to get rid of it, that could help >> confirm our model works (and it would remove the chance of using the >> wrong tdesc by mistake for a thread that has its own tdesc). It's >> probably something that can be done incrementally though. > > Would it be done incrementally by keeping process_info->tdesc but > changing each target in turn to use thread_info->tdesc and ignore the > process_info one? > Given only AArch64 has this requirement at the moment, it may be easier to leave the process-wide tdesc up until the point we can safely/easily switch to thread-specific ones. After that, AArch64 will have potentially distinct thread tdescs while other architectures will have threads sharing the same tdesc.