From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2085.outbound.protection.outlook.com [40.107.20.85]) by sourceware.org (Postfix) with ESMTPS id 66BDE395B06F for ; Wed, 11 May 2022 15:10:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 66BDE395B06F ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=hQhkbD4DvWsSFoUzZTZUOU4yDgcbpLkhG8y71Z4CVpfgtQRC1ElM+BWWhJa80zQTEs3xQ2pcr8e0KQWFjPVQ899q0SuBYwXr4JoS3iiDRj13xq9khQCqSK/iPuV5eM9RPqu2rW9lCNtNbTzLTUbwZBY+791RCUrN/ghPHs60m3HDvtwCo5I5zCcPaMyevZ14/YQYP0X9gNgEMUWEVnyUhdxle7lFGa65+cAC2RT7mWr0qYbAocQazSxoEGB6/cUnRPN4x68wX36SyTjpFMv1y9upashPTBLVX2ZqPWHCIeeoJjXWdhnzldpRcQaxsAg6/SZGFLAA4alBu6OBaFdRFQ== 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=zrK//rERsWAKyC7Vy8GjP3gJ2t7JbHlBxTYlKtWDSDQ=; b=lyfzJwGtiVQpISS4EviWqpMX1OUFehMpVu43iPUjFTPlpYB8ijzittcRiyTmStXZlqtPaDjpg6EkR9NTexLE7PQ/oMSJhcOk5O34pqbafYomfE/oR3Q29lKnbDW8wAGarBe3Jyb7kdSeKHPqUTC8mp0VzRolK7KyfqqtV/ubBmhOYTzCRuYv9H0tQJ80FVO6BwNUYKWOu8pjs9joNjQTT0Y4gR5unP+LRtk/Ijzw+u0OmAtCeU5tgxsSscmuJTqXjyboWF5UKgPixNBFcgtzMJXLekuEGOXtmwowbCu2SP4mYZTYEmyD+SxxgMWsqs84BiWCw+0qKoiq8/1Mp7KeGQ== 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]) Received: from AS9PR04CA0129.eurprd04.prod.outlook.com (2603:10a6:20b:531::9) by VI1PR0802MB2510.eurprd08.prod.outlook.com (2603:10a6:800:ad::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.21; Wed, 11 May 2022 15:10:23 +0000 Received: from VE1EUR03FT054.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:531:cafe::1d) by AS9PR04CA0129.outlook.office365.com (2603:10a6:20b:531::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13 via Frontend Transport; Wed, 11 May 2022 15:10:22 +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; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT054.mail.protection.outlook.com (10.152.19.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13 via Frontend Transport; Wed, 11 May 2022 15:10:22 +0000 Received: ("Tessian outbound 361d68419a2f:v119"); Wed, 11 May 2022 15:10:21 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: cfa45029392eb0e8 X-CR-MTA-TID: 64aa7808 Received: from b10ff0e09300.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 395EBCEE-0CBE-49FB-8CB5-004B834003A1.1; Wed, 11 May 2022 15:10:14 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b10ff0e09300.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 11 May 2022 15:10:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jNIlTvocWb4orNlfacftgRqmbX/Yjb4lgTNENI5DH9A3NXhcWgx+gilC2EtJ0YSO+a6LmuUFULK2vkBd7QscY3E0F52WLHNtK2K3iBC42C3ckfpgDjWi2lg+8geZWCq/QOceSkovUU1EYZ5LlNwOj5qwcsAmju8nUxQs6Km3fmc0jfNaVUxUbs5OHYuNncO8Ijsps3aEZcqPGG4kR89AkSAmtag74YKl6ntR4KrpAZsprD2TWOmULDdMlXyFNuLbZA7Bl705nFHzWeMJ0AhgTqfmxWYXERXLsFoZtx7HCjFghjddi+k60y6kFZgT1t+rDV77VHbeNiY1x8tEOCgycQ== 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=zrK//rERsWAKyC7Vy8GjP3gJ2t7JbHlBxTYlKtWDSDQ=; b=KR2q7VJO1mU/VbPNCHKJd7GHZ41HDpTgIH1HwWRcP9+OVmggS7fsn20VXvLyNGtLWNU+/ZjxyKu2YlouDf7rlMQUnNys0AWit6GXnp20XvEnBFX1pI8pnkgsFzdoNpYQKR/dOb/y6/ZQyXnJQ6oAaF+Ca3bkpIwAffgQAkBgp4cmOlJ6NuxCSCj5Thoq41Am3j1eavnTs56Y9MBsShDN4VwI7fZjdtDOxv8nEw2J/j9HnNR64SD34L45Vl1ToEE4qUk7Np0utuP+SOZCdTUTGy6j29M5oiSeiSdYuLJ9xf0BjEOTMbxmq6/3gnQkolsN1eufQmPLD1fEGWsdc6XQDA== 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 VI1PR08MB3150.eurprd08.prod.outlook.com (2603:10a6:803:46::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13; Wed, 11 May 2022 15:10:12 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7080:6233:cf8f:a8a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7080:6233:cf8f:a8a6%7]) with mapi id 15.20.5227.023; Wed, 11 May 2022 15:10:12 +0000 Message-ID: <51b2f65f-a1ec-15bf-e810-7950c9089a01@arm.com> Date: Wed, 11 May 2022 16:10:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Restoring pc to a different value than lr on aarch64 Content-Language: en-US From: Luis Machado To: Yichao Yu Cc: gdb@sourceware.org References: <257aa215-a141-6d9b-672d-ea8ce209b107@arm.com> <63f63d70-8a55-618c-06e8-22f923c39e02@arm.com> <02ebd5db-54c6-7fba-e75a-fe35cf1253af@arm.com> <763c426d-7a62-bcb9-223a-d1b5b7e8fc03@arm.com> In-Reply-To: <763c426d-7a62-bcb9-223a-d1b5b7e8fc03@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0144.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::17) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1cdf8915-f952-4856-877e-08da33605eb4 X-MS-TrafficTypeDiagnostic: VI1PR08MB3150:EE_|VE1EUR03FT054:EE_|VI1PR0802MB2510:EE_ X-Microsoft-Antispam-PRVS: 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: reBK3Qflijb22Wd4vmR8V6C5Bw17lUCUhMu5UWjxrL04HL+ZZTKJwolY6EugBZZ2z6g6sehxNNlO61sBiGrbbUQq/X18HOCGLdokmbUuX737nEQ5wL3NReX9I8fsMgbkOFgTZKH3B6kiX0yXItJhcgt7v7YHywY0iFiAO12a2tWMMcwL3TeUcwqMs/BPe6Nsvz58M0Yaol+9JN+4G1Z5eUMIhwW1NH6csTJ5J/kUfDCMI1NEsjfxOg1Ty197tu+qeGeTPEgEnqEuR1bS5lhqYnccNBuP3NorH6Ud+hmXUQfSTYk6Iaies9IKnnloD5kkQczM42nFvYHyRjkiYDip6jDGFYD1KCx00UXW+Qhlw5XA+jkt2wQwo06IFTI7/uQOrbAr9GYZrmMe8aCdm7TJCILsVLR/JsuPRHPdYkYBL9n4vXWgWohycRVJbAOT8QPhNklqQRN/IDKW+ffWJnD7UOyb8lZiF1nh6mdzmB+bSHLCtg/QDObmvwsnRhXJwL+PILVaYlabz2QDZ5sJGAdgvTKeZaNfo4aB+KNZvY80bBC19l4cMlxFMHM4MznGoSWufVf6ZshyY+sv/h+VRLCzs1bJLC+aeA7B4w4/R1G72RTZxFH/8q/zhSeg+4bsFGoG5g7oaIsQ5h8K933u756mElBF+hTMxPdvSthCtIGdOyDqs8HluuXLX3G4fTaYheJueV8eIplI+O2STqghQkXmYjSn/BsXBK5bWU+wkA5VAzbLtPlPB5x90dgumrqV6zxe 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:(13230001)(4636009)(366004)(5660300002)(6486002)(4326008)(26005)(6506007)(8936002)(66946007)(53546011)(66476007)(66556008)(6512007)(44832011)(38100700002)(83380400001)(8676002)(31696002)(86362001)(6916009)(316002)(186003)(2616005)(31686004)(36756003)(2906002)(508600001)(21314003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3150 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: VE1EUR03FT054.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 023ff3c5-f8b9-4daa-7fd7-08da33605881 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KcvZKcRNW977sjLG1WIZs3lZMwPo44js+mfcaeM/gDeM1mwVIAqo0vnuY18nQEsSeYOlXR2tG0HBYjUsIph8Yxe73M4/yx0qfmX8SnxGLOuIz3uDdPElv5MNaN/9TWIoPGhfLc4JbFJ4yNp9aioZZy4vCcX9hLp4/w7sy9ze92fTodFmzV1InbX0XTXnic91Y4T8DfFUymlDlX9mSIKqCi0HqFg0B8llaxIM4TUzSogUTNGLRqitwDV5vbUPLf6AJ0KLvFw5zaUO51ByXSXG2FnMgeAmG0f39viUJF6wMnrODp9+uaDD0jO/Ml77oyZx1Vcs57feErIpYad/pnXUpF+vyfL690hugQkbtv+raVfpQ6WVrJc+7rtgSNS8yi6izpDMvmcKRUJDYZGW+Szmxyl303i1DqUjFUDwTOYM96JL61n4nFQ1nj4bUNwSkVHcbggjMZrGjdFrlIQyPbBzNUP4t0JlKt+5iw+GZqHnDIoKEeffIH+qtocra6hFreUoHmrHHp7CRtVCj/nUbQkBiUQelK5ZtKCQenYWLQhqOTu72qwajnsswsTrvdPJsFCR46kH5A6PtFZNp84l0QqfpM8l/gQ3S/DxoTmaARxlSk6STlYSYZ8d+R6aZgIJIQ5X2rJZAg9UZMZHq0NUj+JakydTdJ540sjm7NzXcvCwmPPxRO/4FKpEHJOZdf1YHbVO9VOsLJEKs8vGYiBHRpchx48FgaaT04gb6hRqOl96NSwnyGyq7foJO+gm/nGZ3i/PSWUH7yje0G75rxh2m/9ys/mi7S2FRXVHwa6tZKBffEg= 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:(13230001)(4636009)(40470700004)(36840700001)(46966006)(2616005)(70586007)(86362001)(356005)(82310400005)(36756003)(5660300002)(53546011)(8936002)(6506007)(83380400001)(31686004)(6486002)(508600001)(6512007)(26005)(47076005)(70206006)(44832011)(316002)(4326008)(8676002)(31696002)(6862004)(336012)(2906002)(81166007)(40460700003)(186003)(36860700001)(21314003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2022 15:10:22.3394 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1cdf8915-f952-4856-877e-08da33605eb4 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: VE1EUR03FT054.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2510 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 15:10:28 -0000 On 5/11/22 15:51, Luis Machado wrote: > On 5/11/22 14:26, Yichao Yu wrote: >> On Tue, May 10, 2022 at 10:49 AM Luis Machado >> wrote: >>> >>> On 5/9/22 15:24, Yichao Yu wrote: >>>> On Mon, May 9, 2022 at 6:44 AM Luis Machado >>>> wrote: >>>>> >>>>> On 5/6/22 17:30, Yichao Yu wrote: >>>>>> On Fri, May 6, 2022 at 12:11 PM Yichao Yu wrote: >>>>>>> >>>>>>>>> Actually I misspoke for that. It seems that sp is probably fine >>>>>>>>> and >>>>>>>>> the only thing missing causing pc to not work is that >>>>>>>>> aarch64_dwarf_reg_to_regnum doesn't understand the PC dwarf reg >>>>>>>>> number. It seems that the only thing needed is to add a >>>>>>>>> >>>>>>>>> +  if (reg == AARCH64_DWARF_PC) >>>>>>>>> +    return AARCH64_PC_REGNUM; >>>>>>>>> >>>>>>>>> to that function. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, GDB always assumes the PC from the previous frame is the LR >>>>>>>> from >>>>>>>> the current frame. That is what GCC generates. >>>>>>>> >>>>>>>> If a different setup is needed, GDB needs to be taught about it. >>>>>>> >>>>>>> I agree the current code makes sense for what gcc generates. >>>>>>> However, >>>>>>> I think given the document from arm, explicitly setting the PC value >>>>>>> in the unwind info should also work. >>>>>>> Would a patch similar to the one above be acceptable to fix this >>>>>>> issue? >>>>>>> >>>>>>> A related issue is that gdb also seems to be ignoring the return >>>>>>> address register in CIE. There is at least one use of it in glibc[2] >>>>>>> where the return address register is set to x15 instead. >>>>>>> I've verified that gdb is currently unable to unwind after the >>>>>>> call to >>>>>>> `strlen` from `rawmemchr` even though the return address is still in >>>>>>> x15. >>>>>>> I thought this can be fixed by chaiming that PC is RA just like the >>>>>>> fallback case but that is apparently not working... >>>>>> >>>>>> Actually this did work but the address is wrong before the value was >>>>>> written to x15... So it was just due to incorrect unwind info (the >>>>>> glibc implementation should specify how to find x15 on the entry of >>>>>> rawmemchr). >>>>>> Is the current implementation due to some edge cases? (like old >>>>>> compiler version doesn't put a valid value in the CIE for the return >>>>>> address register). It seems that many other architecture simply use >>>>>> _RA so I don't see why this would have broader problems... >>> >>> This looks like a genuine bug, one that is not hit that often given it >>> is not very common for frame to change the return address column. This >>> will need to be fixed eventually. Thanks for spotting that. >>> >>>>> >>>>> It is probably historical that this has been handled like this. If >>>>> there >>>>> is a use case for having a PC column containing distinct data, then we >>>>> could support that. >>>> >>>> I couldn't find any existed code using this, but it seems that this is >>>> the intent from ARM and I really can't think of any other way to >>>> restore everything including both pc and lr so I'd like to support >>>> that at least.... >>>> >>>>> It wouldn't be as simple as that change you mentioned though, as other >>>>> parts of the code assume PC comes from the LR. >>> >>> I take that back. I investigated this further and I think this should >>> work, although it is a use case that is not so common. >>> >>>> >>>> There are indeed other unwinders (the prologue unwinder) that assumes >>>> this, which I think should be fine. Specifying the PC explicitly >>>> should only apply to the dwarf unwinder. The only other place where I >>>> can find that relies on this is aarch64_gen_return_address. It doesn't >>>> seem that this function is used in most of the other logics and if the >>>> return address column is somehow accessible from here it should also >>>> not be too hard to fix. >>> >>> I think it is only the case for the dwarf unwinder, as that is the >>> unwinder that has access to the CFI information. >> >> Sorry what did you mean by "it" here? (being able to handle PC != LR >> during unwinding?) Do I need to worry about gen_return_address? >> > > Sorry, I meant that we only need to worry about the dwarf unwinder > functions. The other code not relying on CFI information doesn't need to > be touched (prologue unwinder, aarch64_gen_return_address etc). > > At this point, we'd like to augment aarch64_dwarf_reg_to_regnum to > return a valid number for the dwarf PC register. > >>>> >>>> Is there any other cases that I'm missing? I've also tested with my >>>> simple change and it seems that unwinding from normal functions still >>>> works as intended. >>> >>> Yes, I tried it on my end as well and it does work. What I was worried >>> about is that we need to adjust the LR value in some cases. >>> >>> For aarch32 we need to remove the LSB, and for aarch64 we need to unmask >>> the value of LR if it is signed through PAC. This is the reason why we >>> have a custom dwarf2_prev_register implementation. >> >> Is the aarch64-tdep code used for aarch32 tracee as well? >> > > The aarch64 code is not shared by aarch32 (that would be arm-tdep.c). I > just mentioned it because both arm-tdep.c and aarch64-tdep.c use the > same mechanism for unwinding PC. That is, they return LR instead. > >>> gcc and clang emit the return address column as r30. If we don't specify >>> any initialization rule for PC, then the dwarf2 unwinder will go through >>> the route of fetching LR and adjusting the values. >>> >>> On the other hand, if PC is available in a CFI column, then the dwarf >>> unwinder won't call the custom hook and will instead proceed to >>> calculate PC from the CFI expression at that column, which should give >>> the result that you want. >> >> Right, and I guess that means that the custom unwind rule needs to >> take the pointer authentication into account? >> (I've never used any machines with that enabled so I'm not 100% how >> it's supposed to work....) > > It does need to take that into account. But using a custom function for > unwinding PC means we will not have access to > Sorry, this got truncated. With a custom function for unwinding PC, it means that we only invoke such function if CFI is not available for a PC column. If it is, then we follow the CFI rule but don't do any additional processing that would've taken place in the custom function. Given the case of having a PC column is not so common, this should be OK for now. >> >>> We can't initialize PC to DWARF2_FRAME_REG_RA though (not yet, anyway), >>> as that would default to mapping PC to the return address column. For >>> gcc and clang, this would be x30. That would give GDB no chance of >>> adjusting the LR values if required (for PAC-signed LR values). >> >> Just so that I understand, if LR is signed, then upon return it should >> still have the signed value. (Or in the case a different register is >> used for return address, `ret xn` would not change xn value) >> Only the resulting PC should have the signed part masked off. That's >> why the unwinding of LR is correct without any post-processing logic >> as-is but the unwinding of PC needs to be treated specially. > > > That's correct. > >>> It would be nice to have a testcase for this, alongside your patch, to >>> make sure GDB is always doing the correct unwinding. >> >> The part for returning the name of PC is easy. I assume the test would >> be mainly throwing in a aarch64-xxx.{c,exp} and to check if explicitly >> specifying the PC in the unwind info result in valid unwinding. I'll >> try look for some but any examples that I can follow? > > I think gdb/testsuite/gdb.arch/arm-disp-step.{S,exp} is a good example. > Basically, some .S file that contains some random instructions and CFI > directives that we single-step over and check if GDB is following the > values of the registers correctly. The .S file gives us more control > over those CFI directives. > >> This should fix the case where PC is explicitly specified but wont fix >> the case where a return column is specified. Handling that requires a >> different way to post-processing the PC. > > Correct. That is a separate bug and I'll need to investigate that. > > Thanks! > Luis