From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30086.outbound.protection.outlook.com [40.107.3.86]) by sourceware.org (Postfix) with ESMTPS id 37CC038485B1 for ; Mon, 9 May 2022 10:44:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37CC038485B1 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=BgwRAlU/mpGPJCFivr8GgoH7z6MAngk+23HJtjvPaLia4PCXK9nMlBu9ono+LU7aRwmmLYsbyYbNLUsMa2oC6mmBGhO0pS0DIWciogJvtXBfwDxuawEhHO6IHT5mP0Rx9AMoB6FwkYrUqe+7EXUDLjFt0HJyejkY+Fd/zJ6tuV9MW2PJIpLXdIkfsAiLMO+fj+e34rlaz2CS1WIxnB0buZrtKT0k26zTWdPnx8HeBWnRAh2NeY1UkdO8FYZo1MrKhTNp4s2JbbZFoD84/NcbN2Gk5NQXGSbhBxeDvqUMJl9c6rOcc9myY2r+NQir7sPpD8kAcjyoakzTFM+GbIotaw== 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=//LWAHsTs7Y8rCeSMi2cNcUHJzJ7j3Z+fkA7fJKE+3o=; b=gvPSGiZVLKsVB5YMQQspCrx7pKnas5Iwx68rUI6K/PL+AYV+yE/C94oqqhFjwixIigzrYSs31ouyNeevv6QKOp1bne3yoW2Itd7+BQGFD+mXzIKxSMZKS+o98OQdNwnyNyYaalSD3XwnO9KgN4kIYk7oQvqwU7Z7OZfvtJv44sxMPQSZexPULrPtdMb2cb1oX6p7zOYrj6lFXKspv8Ysr4TbkjOcRHTO5ZmrUXpoL6rrZDZf4bYbgyuhAxcl4kVK7WLKt8bnZpdyQX1N3hXxfK8h/c1Orcl/4Y9GsrCw2FW/3RJa8hRpjYR5A/x9lkU7DMtN6Ya/mOcS/2+5Z5LX8A== 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 DB6PR07CA0179.eurprd07.prod.outlook.com (2603:10a6:6:43::33) by GVXPR08MB7728.eurprd08.prod.outlook.com (2603:10a6:150:6a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.20; Mon, 9 May 2022 10:44:40 +0000 Received: from DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:43:cafe::ce) by DB6PR07CA0179.outlook.office365.com (2603:10a6:6:43::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13 via Frontend Transport; Mon, 9 May 2022 10:44:40 +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 DB5EUR03FT013.mail.protection.outlook.com (10.152.20.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.15 via Frontend Transport; Mon, 9 May 2022 10:44:39 +0000 Received: ("Tessian outbound 9613c00560a5:v118"); Mon, 09 May 2022 10:44:39 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f1b80e676b5ba702 X-CR-MTA-TID: 64aa7808 Received: from cd3b57178de1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 54DF7A72-2E2E-4BF6-B1FC-58AE2CC6F0B2.1; Mon, 09 May 2022 10:44:33 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cd3b57178de1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 09 May 2022 10:44:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZiZ+S+DJlGF21+NioTo1+NzueA2bzOPwd5YRdVaqYAUGQ8iLK7C4CqOnqI6nIvuo5evdFrgD1iE0cYjqx/owu5pvhrETltTony6QP5VQ8o/VJsgHP+hPOTUnbmYl+8cBUWJrhq4NfKweS4ysBGj50BrLRQlRcbPNegY0d3ta7Qrc5IkGH+53SBjH6EBORYoejTeq+jbUMVvPBVhVAkYTuYZsb82xPtoMWMYDoq6tFTzH9AAlk7r82znwFQvu484GN4mNFQd3skoeByzjiNl3T7Y80k5divmxLsPdiQmcHT7znm+SxRDbexOEf14wkP0VOLFOWmv7+voLC3G9H3WMcA== 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=//LWAHsTs7Y8rCeSMi2cNcUHJzJ7j3Z+fkA7fJKE+3o=; b=VmWWf2lHOvMCyWVsBrQaR4Qua/34sq0/NfgSy6sh3XPEpgkOBnvEB2J4WsBXuGfujQaynWz7KzEDTFRj7sIj1ELcSHZ+3ioo669Pzn8hc8OgdnvgAobcR68qN+i4UTTUL5RPphIGMPLKUiIdj6+NvxFW79yvXzRgZhQYjocouOoEwx9TcmJ9HfRcr1NyQ5FfTIy9EQrPXVRdl/13ZLUi4U2rDpKwjpYrqvTsh3c7Hpb+JYuNOfnsqDbvcpvFNasoHjm8wLK1KdlTFTq4sMAgQ4UEvH2R2Po8QPCSa2qg1C7qbrNTlt3jM46LocEFte4ndIh4E0GRIIsEyxgRzClcTg== 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 AM0PR08MB4578.eurprd08.prod.outlook.com (2603:10a6:208:100::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.18; Mon, 9 May 2022 10:44:31 +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; Mon, 9 May 2022 10:44:30 +0000 Message-ID: <63f63d70-8a55-618c-06e8-22f923c39e02@arm.com> Date: Mon, 9 May 2022 11:44:25 +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 To: Yichao Yu Cc: gdb@sourceware.org References: <257aa215-a141-6d9b-672d-ea8ce209b107@arm.com> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0283.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::18) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 3c9742d6-84dc-4797-6a40-08da31a8eb60 X-MS-TrafficTypeDiagnostic: AM0PR08MB4578:EE_|DB5EUR03FT013:EE_|GVXPR08MB7728: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: FsDZy1METSNPfpM/oNCGEVOnjOLhGZaWw//j5w+V4y4lAV08Rk7PImOD1qYd8au5RJip4fZt7v4NwqJ36/8kGgieyZ/r2t5L5ll/jlN8Sy6T2Erw+JiTF56ADaTJW7wrl5wf3JibYjmNELqDfmgAxYUnwFGhNheWU2Q+t/YkamUjWamHwgfwPlkI8ZGESzjK5OOD7smg0zR+a23Dq3cQ56o7p8nEZ/D8r+5p7r8MNwYhQaPp4RaVDS1liVWmMiCVNj2WJfSiGmDnYsWPgErGUmpVmZc9wdrBRk39Bn5Vgrpp+zI4kkzb5SWUMU364FPrs6G6KbXOQ67boIpmoPWdLZgHtl4qnyO1nJG9oPXREMZ4mUyvBTQc3GylVnXd54itKhCcBKoNX8mjHDm5gJhvVwFHr7T5t1d2/LgF/hF2EOEEOOVZAtPZAUGbcj8Mx3QIICDEjtF+nEwUqrY1fWSt9ZkDkS4STtrDMtb0nsYrdG3JoKcUN4/8fsWOMreFxwAw/WCM9D5fFHswombh28ZtvMEzMPHClI8xQW5XcdARkgOhseLAFYYnPb/JQTApoDwH9IR3QKuZcspnFmtTJOzR2zPFz6+Bvdip7xl4CfbbmZzUVkSFJX5uDNij4WlsBkCMbsNBcL7sAcQ7Ai3ZQd1z4Q4OZRBmsdHijkZFp58eZtw6EisasyFDQrJiUFyVRQ7NiSwBHhP6TtqyTklt8sueMfNQ+zS+nuTy7bHbmg3xnTAGOrpN4Ao/KZ9emcVI5rUO3OV5rDzti1TOI8fqg5QXWIyXkV1e6RQNj9dtrVx0xenvYIwVE730L1R5beOb+6PZQqZe/hBJYpiN5suXuU6d4HUVLj08Q9eX0zcxk63PWIE= 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)(31696002)(6512007)(86362001)(6916009)(8936002)(44832011)(966005)(53546011)(316002)(6506007)(6486002)(5660300002)(36756003)(508600001)(38100700002)(4326008)(6666004)(66556008)(2906002)(8676002)(31686004)(66946007)(83380400001)(186003)(2616005)(26005)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4578 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: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: aaf64b3c-cf90-48fa-3580-08da31a8e53a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IaSACUWRNB6z8HBj+Gkly5v8tYTLU5kwM3ZYDrbiZdNlxSa/3U15ID/6ZS9hSQt2xukOoQ9PREJ2Qu8DVYkEmNPbQPwihIkDOk1JNRknHHoWzsJFTMpNepRi1q4QhAKFxoIlFomZxCB7nc0W+NPYjIymymgX+9Rc3tYs570t3WqMH7u7//aBdAhTBC5AAXaksc3mJL2+zAi+cX4huiuSL1VXTvqLR67uIpJ1/8V/L31Vqu+vSCRhdLyEONTjHRt+BYW0Wo1ZjIyHYnwrkC5KVBBWNr1miCNMqUlHw1MGjG9ahVfdTpUo3cUhNY5Ec2vIs4K6jmNFGuS3dqd54aWuV762EPXM6hyetW3BSiMj/KRADDFVwlGV/sit7DZNbjxh5gyiIVBhIvobXYfOi8e7MFuN0jyl85GIbvB5bgL1/ar5qKF2pTggM907/P0/4H/yOMz47O0oRXMQmb/ZGaceu7ZWou2qq2o4dX0H18Y1Eo1e1eqX231wJZc7A90EuYy8nnSH+kjxvY07XFIxiZtzgO1EN0xh78KN6vKkXFTdIj60l/oqiv6NK6FnBNxOpCMLaYZhXVsVVdKjY0b5jUFINd87tqBxtbo0uAasaHNECWZ5WP5rt6jD5b1Kh111RClEktLfANKLT0mTPDP9KdytTnUJrl0zC5aTvB8USNV2D/7zxdiHJM9rbLdAJo3v+TZb+lfhMVJ3hxgLARgXtg6THxtU4Oxsno5hTzyMl9VOopYfHcGK4ODq6ClwsLIGTfedErmp7n9kzcwRN30enJJUXN8/U6aLzVIihPfi10EV41IFbfd3HTBappZlrYmZ5/+jRlpRfqK8ciQelzG2MAJtkQ== 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)(36840700001)(40470700004)(46966006)(8676002)(5660300002)(8936002)(966005)(44832011)(6486002)(336012)(508600001)(47076005)(356005)(36860700001)(86362001)(26005)(40460700003)(31696002)(186003)(6512007)(2616005)(2906002)(6666004)(83380400001)(53546011)(6506007)(316002)(70586007)(70206006)(81166007)(31686004)(4326008)(82310400005)(6862004)(36756003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2022 10:44:39.9487 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3c9742d6-84dc-4797-6a40-08da31a8eb60 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: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7728 X-Spam-Status: No, score=-7.3 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: Mon, 09 May 2022 10:44:45 -0000 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... 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. It wouldn't be as simple as that change you mentioned though, as other parts of the code assume PC comes from the LR. PC is probably specified as DWARF2_FRAME_REG_SAME_VALUE (as far as I remember), so it will cause some issues during unwinding. There is a comment in gdb/dwarf2/expr.c about some odd cases. For example: /* GCC, in its infinite wisdom decided to not provide unwind information for registers that are "same value". Since DWARF2 (3 draft 7) doesn't define such behavior, said registers are actually undefined (which is different to CFI "undefined"). Code above issues a complaint about this. Here just fudge the books, assume GCC, and that the value is more inner on the stack. */ > > >> >> [2] https://github.com/bminor/glibc/blob/b92a49359f33a461db080a33940d73f47c756126/sysdeps/aarch64/rawmemchr.S#L34 >> >>>>> >>>>> According to aadwarf64[1], >>>>> >>>>>> having both LR and PC columns is useful for describing asynchronously created stack frames. A DWARF expression may use this register to restore the context in case of a signal context. >>>>> >>>>> so assume the intention is that if I explicitly unwind the pc in >>>>> addition to lr, it should work. I tried to do that, and also to set >>>>> return address column to 32, as well as trying to mark the frame as >>>>> signal frame but none of them seems to work. Is there any way for gdb >>>>> to honer the explicit unwinding of pc? >>>>> >>>>> Also it seems that the sp is also card coded to be cfa. My code also >>>>> contains explicit saving and restoring of that as well so if that's >>>>> the case (haven't tested yet) it would be a problem too... >>>>> >>>>> Would it be possible to not use this hard-coded logic if the frame >>>>> contains explicit override of the pc value? >>>>> >>>>> Yichao >>>>> >>>>> A bit more about the actual code. This is done as part of runtime >>>>> patching code. The actual restoration of lr is done by returning to a >>>>> runtime allocated stub that restores lr and directly branch back to >>>>> the return location. After returning, all registers values are >>>>> restored back to their previous one. The stack pointer is also >>>>> switched out since we cannot rely on how much stack space the call >>>>> site has available. >>> >>> This seems to work in a similar way as signal handler. GDB needs to be >>> taught where to find the registers so it can properly unwind things. >>> >>>>> >>>>> [1] https://github.com/ARM-software/abi-aa/blob/8a7b266879c60ca1c76e94ebb279b2dac60ed6a5/aadwarf64/aadwarf64.rst#note-9 >>>