From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id NjHNCb1K+2KS1ScAWB0awg (envelope-from ) for ; Tue, 16 Aug 2022 03:43:57 -0400 Received: by simark.ca (Postfix, from userid 112) id 1818D1E5EA; Tue, 16 Aug 2022 03:43:57 -0400 (EDT) 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=Sw/kF1f2; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham 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 DB7EB1E222 for ; Tue, 16 Aug 2022 03:43:55 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 49B673858429 for ; Tue, 16 Aug 2022 07:43:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 49B673858429 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1660635834; bh=9lpxJmkX6j6JtrS49/nBMpx4UKIwsw5aEI2ZLEr0aVs=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Sw/kF1f2LaGZMavEJzj/5lh+7GOP5VCxRiABEsIk4ddzs0A+1ssVvxWXY4h0qHyMU DDmBmmV/IIApcqZOPdazoc+YPhaQJAyT6Kb4d8zhspxQ9xfw1AR3WK4uqOrD8ktg9l wubj3LuXWNOfow07pVF8QdoJwt0Ps4OtYNQsqIg4= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130089.outbound.protection.outlook.com [40.107.13.89]) by sourceware.org (Postfix) with ESMTPS id 0A9083858C20 for ; Tue, 16 Aug 2022 07:43:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A9083858C20 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Gfcz4LAEF4KtwGcLEcMMmWiPUQH/K9yfEBLSvaQ1mFmtOP/xjX8l5bjMJOFdcweuMefMW1NBqNryqtL9N0tEfQvWF8zDizBkj5zhLhJqQObzAp5/knzQfhoYnH4CH6ImZPAWmYuh1q76Jv757jTjQ35sUsiDJIWdQQySj9p/StzLwrka+9KC9rqilvN8bWw3G7hcowPtogaXz9GXWEE4QlvtoboDy7K5memIdZF2jIiVJaWUqKAxzp2BD2XHsvApSQCpfM2yOjjrAtO6/IYe0Qwv9NpmRuLK/314F/vYPOK/UxGlt8zKIVijFg80QnwBES+WMrge8mlT6HyN45Q50w== 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=9lpxJmkX6j6JtrS49/nBMpx4UKIwsw5aEI2ZLEr0aVs=; b=LEff0HxZZIIuurRHbKnietUde4fvhH1iEwwefcdEJAkDyJ123vS1wG6em49Hwi47rz6OPIXaMMD+FINrclCMVP4zV+/qmWOApkl4GXEp+hwCXHYdDuAowt/SOHrUSf6noBWGgsSOv4FvGB5gZezgYv04e6NYapUOh7lh+abmi9CF8e70P9oFuuotbL9IIraozyXRXvCFfx2p4fV5mi0vECttnhdkTDx3HjTgXuMxJt/wFpYraZRorISeQ1EvTO98J8c7gGbtdNisp+g9gXsFWSSUmX81sR8ukdv7LrM6jRAd0UhSQl7nRy1eJsyQ29JEStKjka3RtcuJIN/9g+fdgg== 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 FR3P281CA0114.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a3::6) by DB6PR0802MB2358.eurprd08.prod.outlook.com (2603:10a6:4:89::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.16; Tue, 16 Aug 2022 07:43:28 +0000 Received: from VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:d10:a3:cafe::4b) by FR3P281CA0114.outlook.office365.com (2603:10a6:d10:a3::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.15 via Frontend Transport; Tue, 16 Aug 2022 07:43:27 +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 VE1EUR03FT007.mail.protection.outlook.com (10.152.18.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.11 via Frontend Transport; Tue, 16 Aug 2022 07:43:27 +0000 Received: ("Tessian outbound c883b5ba7b70:v123"); Tue, 16 Aug 2022 07:43:27 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5145743108650a68 X-CR-MTA-TID: 64aa7808 Received: from fec3c7972484.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EDF611FF-F030-4CAE-B66B-9881E9D3F700.1; Tue, 16 Aug 2022 07:43:19 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fec3c7972484.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 Aug 2022 07:43:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IkrsI9fNvDEeTp0+H8twrVF7VD2zjKXRnc7tpGpliRKKUeWLAR3910zDixCEMgSqEyUlQzrnTuI16/+taUjmHsFJxRNJSBS6yWgYD4xyu7ZJKBZbqYcJlHaGGY9nzeYU6fgl15zbhvI6dkAXYBXeoA+tX87kf2ihFKw2jmlwfCjH9Fi2q6p7v/0ueBogW4cuV46jlspC8vHeMlAVa7u36TKgrm4efu5Na91XJodSjRIVKl8PMiSRwtnJA+P4qOyQegkqy79iKp/qZ/LVVFDWYe9ajN5edSS24nwLi9UZymCA9g0dGk9x79hmcQ/bpshFZHtrqmH0SsMyoZim79FkAQ== 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=9lpxJmkX6j6JtrS49/nBMpx4UKIwsw5aEI2ZLEr0aVs=; b=DwNSeGIjyoJxLUTujm8y1gF8ElTOHibOCoOX1/XCZ2+tE9xNFJNFlNs9YeAtcCpbRF4b3ve6NifC+Dym79IjKs84WNx1izbvo8m1Yi7uVjRYMcKvNpTYTHfuVj0YoT9xc1PX26x2uvuaR9/r+rQ9QtsiaqwRLr2pgTRxOJGCzqwz6mLvdmqbyez1ClNQoBMxWYzQ92Q+PoDEaQZyHx+s05F3MegociGtDGUCczGb8H6HFvREjE7gcN8anueGRNaR9PPHQkWf1SK/ttdIawYRjHsna1nS7oMxynao7I/hOQByo4N8iRH/TCOBJ1CvOvHNoXEbgIxs/YKEk3Y1LhuPIQ== 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 HE1PR0802MB2203.eurprd08.prod.outlook.com (2603:10a6:3:c3::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.14; Tue, 16 Aug 2022 07:43:16 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::cc64:9170:b12d:de8]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::cc64:9170:b12d:de8%4]) with mapi id 15.20.5504.028; Tue, 16 Aug 2022 07:43:16 +0000 Message-ID: Date: Tue, 16 Aug 2022 08:43:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp Content-Language: en-US To: will schmidt , Carl Love , Tom de Vries , gdb-patches@sourceware.org, Ulrich Weigand References: <20220811115809.GA19509@delia> <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> <10b3195562b41db8f77d3c0cbd984d0da270190e.camel@vnet.ibm.com> In-Reply-To: <10b3195562b41db8f77d3c0cbd984d0da270190e.camel@vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0372.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::17) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ec548624-2731-40ee-8f6a-08da7f5b01db X-MS-TrafficTypeDiagnostic: HE1PR0802MB2203:EE_|VE1EUR03FT007:EE_|DB6PR0802MB2358: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: 7QYCq4cBSXbV/fCIyoXKSHRDr/szMYg/SXY23F10nbmKQSRX1OZ5AkRvAe2NCkM65L+1w6FdmxKsvXLfY59XQaTgZH9h2S70xiPNWirEpICobvDUfMoPJxoHf85nvevfpSJJE9Q0lOAD8MhVnav96VwwawzesTK8WWAireLHXjkcaXQX1NTw5CDFNpih4cwG+5axaLWtWpL5O+LdYqJWnuGHNxFDIGSlwfKLRKa81VGYdW4LPk8p2eQk5enIH7xRoY9iVuej2yJPX+VnIS9j2zDzYe2CDVw/ovxwl1cRMlXYbmuM4DhFd6tyT3TUe/W2lFuOJnoIUW9/PgOk/uQ/ag9mMxjKm+/83IIZKb5qbwuX2Ya224CogDGDNLStemto5OJnd6J3QVtvS2mEp9ab1+MiQAO7kyFOnkKX34bUbeTCZRSomC48BeDxQfLPrFecn71zssKr30tgpaobYY6F9tBax/IDFu5H1/fI5h1TbxxVmYorgJxtO6d3QQaEIidcUD2sJdoa35fpoATrFXm56HqHAjJ9a+qiwzONWqRrnBmMJTi/76ycfrX/shIP4YwMnymKekvOzBN9Qvy5fDdnah2iFNbGyAWaH0+6UOoSFwZ7VUgKG/E3OUqvTvY9Gljkq+YOmVxJa1atCy7PH7dt9Jr+LIkTIHYoJWjxdw1T3uXc1MmIEyBZuNHrz6GwmDTxVovTrIT18796CCRn4Y2xfM4zt7hZC6MUXDtuCKRDEt8MZUyzIuFk/oL9bqFBv1muFSKZ6ZUtlGswtKOTgnfemTO3S8vONgAnnxsyIVHJWodKGK7yoS9mYn0b40hDORlGFl2raxgPcNCeM1Z2h1BU0w== 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:(13230016)(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(66476007)(66556008)(316002)(8676002)(110136005)(8936002)(30864003)(38100700002)(66946007)(44832011)(2906002)(5660300002)(86362001)(6506007)(36756003)(41300700001)(53546011)(26005)(6512007)(478600001)(6486002)(83380400001)(31696002)(31686004)(2616005)(186003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2203 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: VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ea3ccb06-3c56-44d3-b2c3-08da7f5afb38 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cplM+qWvR2UEiXi2me6QnU8pPG0IfwkRi7IQ+2gpOzeDhVknseegoXNKi4MKhAzLh5OOpfwKHPXPn3xCwQoi5wL/XEAuaDizOrqXPxJYeEeAb2z/b4pcNeEDk+v4i/MbebrBAoJBHxFL6qRbGwuzEuF0oPmGuK8GhbqmR0hqw5XfIzbI4+ya9YUSS2dF6uObAZ6GoljjUcK0xk4zZzuk5+bXBqY8tcczuc/aPvK/3dhgoWlbXIqvL4JlRZIRIS4vhLmxIXfRlzmLuPw0Ykkto8Drk3Bv7i6yNUzctuuJM3lxA1jlGn8kMiAKN6NQfLohlJY24zF2+GbL0emP8ALWUAOa0xAaeFejMNs3+ubmjfc8ryEsPIQOT/rm2WtN/iSB4u0126Frnh3oDQfnbQX9eYMP9U21RXOXXYyRttNM2Vc7IaBewpeeMw46Xd06y45is2gf1czO92/yVunby1rET/BPI8stoRBVtDq80Zsoue+kugHuUCWpwlwypDgI/A5YXlW30apwOFqydeTwqdfVJES4gzsJvzbiefGSs85DcfSN+42XxEmIWP+cmdbyc5Ea2IdL/VANaqs04oV2OvU0bo0hbH9ageP9Q3I93hmrlG2Bwd9/ukgaeeEzCq9wx4QkpVGPLVIFUn6gB3QhdLJrPK2V3mxH1F0YS7+LsQnBZRAgNjyDluDAss3hWOFJ7nSSYvpNA+Avm8LggiuyTAqRFqPPmA/L+4d4f7jI6RHx8srGUxD9ZeRBaM9Oe+wV0PWufF4kaMXmzxPm8uyBcxD4bc3QAxDBSaD6d6GcOwhfmTEQNvHC7onUdUvNStT9xUeUmQ2+z14ZxtLM3EBBrJF96g== 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:(13230016)(4636009)(396003)(136003)(346002)(376002)(39860400002)(40470700004)(36840700001)(46966006)(40480700001)(26005)(6506007)(53546011)(6512007)(41300700001)(110136005)(82740400003)(356005)(81166007)(40460700003)(6486002)(478600001)(36860700001)(186003)(82310400005)(47076005)(86362001)(31696002)(336012)(2616005)(83380400001)(70586007)(8676002)(5660300002)(31686004)(70206006)(2906002)(8936002)(36756003)(316002)(44832011)(30864003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Aug 2022 07:43:27.4701 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ec548624-2731-40ee-8f6a-08da7f5b01db 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: VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2358 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 8/15/22 20:12, will schmidt wrote: > On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote: >> Tom: >> >> OK, I took a look at how the test used to work and how it is now >> working and I see what the issue is. >> >> PowerPC has two entry points, local and global. The test used to set >> the breakpoint for the function at the local entry point. With your >> changes, the breakpoint is now being set at the global breakpoint >> which >> is before the local breakpoint. The function is actually entered at >> the local breakpoint thus gdb never "sees" the breakpoint that was >> set. >> Specfically, here is the objdump for the test: >> >> 00000000100006e0 : >> 100006e0: 02 10 40 >> 3c lis r2,4098 <- Global entry point >> 100006e4: 00 7f 42 38 addi r2,r2,32512 >> 100006e8: f8 ff e1 fb std r31,-8(r1) >> 100006ec: d1 ff 21 f8 stdu r1,-48(r1) >> 100006f0: 78 0b 3f 7c mr r31,r1 >> 100006f4: 00 00 00 >> 60 nop <- Local entry point >> 100006f8: 28 81 22 39 addi r9,r2,-32472 >> 100006fc: 00 00 29 81 lwz r9,0(r9) >> 10000700: 01 00 49 39 addi r10,r9,1 >> 10000704: 00 00 00 60 nop >> 10000708: 28 81 22 39 addi r9,r2,-32472 >> 1000070c: 00 00 49 91 stw r10,0(r9) >> 10000710: 30 00 3f 38 addi r1,r31,48 >> 10000714: f8 ff e1 eb ld r31,-8(r1) >> 10000718: 20 00 80 4e blr >> >> When I look at the output before the patch, we see: >> >> Breakpoint 2, 0x00000000100006f4 in >> compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file- >> name.c:999 >> >> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: continue to breakpoint: >> compdir_missing__ldir_missing__file_basename >> set filename-display absolute >> >> >> Note the breakpoint 2 address is 0x00000000100006f4 which is on the >> NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of >> the >> code when the function is called via the global entry point. So >> previously, the breakpoint was set at local entry point. >> >> With the patch, we now see: >> >> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line >> 999. >> (gdb) continue >> >> Continuing. >> [Inferior 1 (process 2520351) exited normally] >> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: continue to breakpoint: >> compdir_missing__ldir_missing__file_basename (the program exited) >> >> Now we note that the breakpoint 2 is set at 0x100006e0 which is the >> global entry point. >> >> It looks to me that we need to make sure we set the breakpoint at the >> local address. >> >> Off hand, I am not sure how to get your changes to "proc >> gdb_continue_to_breakpoint" to select the local entry point not the >> global entry point. Perhaps Ulrich has some ideas??? > > > From a glance that the patch that updated dw2-dir-file-name.exp; > ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 ) > the change there was effectively > > - gdb_breakpoint $func > + gdb_breakpoint *$func > > with assorted regexp changes to match. > > The patch description goes into detail, but I interpret the gist of it > as avoiding the aarch64 architecture prologue skipper, since that > prologue skipper does something wrong, with entanglements in the line > table info. Though the aarch64 prologue skipper is indeed mistaken here, Tom's patch only makes the test less reliant on whatever prologue skippers do and instead just got for a breakpoint straight at the entry point. It is a void function with void return type, so no much going on. Maybe it needs to be adapted somewhat to the PowerPC case? > > The powerpc prologue skipper (wherever it is) was presumably handling > the local/global entry points properly. Since the test now species a > specific address (*$func), the prologue skipper is no longer involved. How does powerpc handle a breakpoint at a particular address? > > The patch should probably be reverted, but I defer to others if I've > misunderstood part of this issue.. > > Thanks > -Will > > > > > > > > >> >> Carl Love >> >> >> On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote: >> >>> Looks like the patch was applied last Friday. We are now seeing >>> 129 >>> test failures related to this commit on PowerPC. The failures are >>> seen >>> on Power 8, 9 and 10. >>> >>> Here is an initial bit of the failures: >>> >>> ... >>> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999. >>> (gdb) continue >>> Continuing. >>> [Inferior 1 (process 2520351) exited normally] >>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: continue to >>> breakpoint: >>> compdir_missing__ldir_missing__file_basename (the program exited) >>> set filename-display absolute >>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: set filename-display >>> absolute >>> expect: /home/carll/GDB/build- >>> current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir- >>> file-name.d/rdir/tmp-dw2-dir-file-name.c >>> frame >>> No stack. >>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: absolute >>> set filename-display basename >>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: set filename-display >>> basename >>> expect: tmp-dw2-dir-file-name.c >>> frame >>> No stack. >>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: basename >>> set filename-display relative >>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: set filename-display >>> relative >>> expect: tmp-dw2-dir-file-name.c >>> frame >>> No stack. >>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_basename: relative >>> set directories >>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >>> compdir_missing__ldir_missing__file_relative: set directories >>> break *compdir_missing__ldir_missing__file_relative >>> Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line >>> 999. >>> (gdb) continue >>> The program is not being run. >>> >>> etc. >>> >>> === gdb Summary === >>> >>> # of expected passes 129 >>> # of unexpected failures 128 >>> >>> I have not had time yet to try and dig into the failures to figure >>> out >>> the cause. I will take a look at the failures to see what is going >>> on. >>> >>> Anyway, just wanted to let you know what I am seeing on PowerPC. >>> >>> Carl >>> >>> On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches >>> wrote: >>>> On 8/11/22 12:58, Tom de Vries wrote: >>>>> Hi, >>>>> >>>>> When running test-case gdb.dwarf2/dw2-dir-file-name.exp on >>>>> x86_64- >>>>> linux, we >>>>> have: >>>>> ... >>>>> (gdb) break compdir_missing__ldir_missing__file_basename^M >>>>> Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line >>>>> 999.^M >>>>> (gdb) continue^M >>>>> Continuing.^M >>>>> ^M >>>>> Breakpoint 2, 0x00000000004004c4 in \ >>>>> compdir_missing__ldir_missing__file_basename () \ >>>>> at tmp-dw2-dir-file-name.c:999^M >>>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ >>>>> compdir_missing__ldir_missing__file_basename: continue to >>>>> breakpoint: \ >>>>> compdir_missing__ldir_missing__file_basename >>>>> ... >>>>> >>>>> When trying to set a breakpoint on >>>>> compdir_missing__ldir_missing__file_basename, the architecture- >>>>> specific >>>>> prologue skipper starts at 0x4004c0 and skips past two insns, >>>>> to >>>>> 0x4004c4: >>>>> ... >>>>> 00000000004004c0 >>>>> : >>>>> 4004c0: 55 push %rbp >>>>> 4004c1: 48 89 e5 mov %rsp,%rbp >>>>> 4004c4: 8b 05 72 1b 20 >>>>> 00 mov 0x201b72(%rip),%eax # 60203c >>>>> 4004ca: 83 c0 01 add $0x1,%eax >>>>> 4004cd: 89 05 69 1b 20 >>>>> 00 mov %eax,0x201b69(%rip) # 60203c >>>>> 4004d3: 90 nop >>>>> 4004d4: 5d pop %rbp >>>>> 4004d5: c3 ret >>>>> ... >>>>> >>>>> And because the line table info is rudamentary: >>>>> ... >>>>> CU: tmp-dw2-dir-file-name.c: >>>>> File name Line number Starting >>>>> address View Stmt >>>>> tmp-dw2-dir-file- >>>>> name.c 999 0x4004c0 x >>>>> tmp-dw2-dir-file- >>>>> name.c 1000 0x4004d6 x >>>>> tmp-dw2-dir-file-name.c - 0x4004d6 >>>>> ... >>>>> the address does not fall at an actual line, so the breakpoint >>>>> is >>>>> shown with >>>>> address, both when setting it and hitting it. >>>>> >>>>> when running the test-case with aarch64-linux, we have >>>>> similarly: >>>>> ... >>>>> (gdb) break compdir_missing__ldir_missing__file_basename^M >>>>> Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line >>>>> 999.^M >>>>> ... >>>>> due to the architecture-specific prologue skipper starting at >>>>> 0x400610 and >>>>> skipping past two insns, to 0x400618: >>>>> ... >>>>> 0000000000400610 >>>>> : >>>>> 400610: 90000100 adrp x0, 420000 < >>>>> __libc_start_main@GLIBC_2.17> >>>>> 400614: 9100b000 add x0, x0, #0x2c >>>>> 400618: b9400000 ldr w0, [x0] >>>>> 40061c: 11000401 add w1, w0, #0x1 >>>>> 400620: 90000100 adrp x0, 420000 < >>>>> __libc_start_main@GLIBC_2.17> >>>>> 400624: 9100b000 add x0, x0, #0x2c >>>>> 400628: b9000001 str w1, [x0] >>>>> 40062c: d503201f nop >>>>> 400630: d65f03c0 ret >>>>> ... >>>>> >>>>> But interestingly, the aarch64 architecture-specific prologue >>>>> skipper is >>>>> wrong. There is no prologue, and the breakpoint should be set >>>>> at >>>>> 0x400610. >>>>> >>>>> By using "break *compdir_missing__ldir_missing__file_basename" >>>>> we can get the breakpoint set at 0x400610: >>>>> ... >>>>> (gdb) break *compdir_missing__ldir_missing__file_basename^M >>>>> Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line >>>>> 999.^M >>>>> ... >>>>> and make the test-case independent of prologue analysis. >>>>> >>>>> This requires us to update the expected patterns. >>>>> >>>>> The fix ensures that once the aarch64 architecture-specific >>>>> prologue skipper >>>>> will be fixed, this test-case won't start failing. >>>>> >>>>> Tested on x86_64-linux. >>>>> >>>>> Any comments? >>>>> >>>>> Thanks, >>>>> - Tom >>>>> >>>>> [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp >>>>> >>>>> --- >>>>> gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++---- >>>>> gdb/testsuite/lib/gdb.exp | 7 ++++++- >>>>> 2 files changed, 10 insertions(+), 5 deletions(-) >>>>> >>>>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>>> b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>>> index 4d3f767f597..4c4c1ff07af 100644 >>>>> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>>> @@ -396,20 +396,20 @@ proc test { func compdir filename } { >>>>> error "not absolute" >>>>> } >>>>> >>>>> - gdb_breakpoint $func >>>>> + gdb_breakpoint *$func >>>>> gdb_continue_to_breakpoint $func "$func \\(\\) at .*" >>>>> >>>>> gdb_test_no_output "set filename-display absolute" >>>>> verbose -log "expect: ${absolute}" >>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp >>>>> ${absolute}]:999" "absolute" >>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp >>>>> ${absolute}]:999" "absolute" >>>>> >>>>> gdb_test_no_output "set filename-display basename" >>>>> verbose -log "expect: [file tail $filename]" >>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp >>>>> [file >>>>> tail $filename]]:999" "basename" >>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp >>>>> [file >>>>> tail $filename]]:999" "basename" >>>>> >>>>> gdb_test_no_output "set filename-display relative" >>>>> verbose -log "expect: $filename" >>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp >>>>> $filename]:999" "relative" >>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp >>>>> $filename]:999" "relative" >>>>> } >>>>> } >>>>> >>>>> diff --git a/gdb/testsuite/lib/gdb.exp >>>>> b/gdb/testsuite/lib/gdb.exp >>>>> index a8f25b5f0dd..70fc019eeb9 100644 >>>>> --- a/gdb/testsuite/lib/gdb.exp >>>>> +++ b/gdb/testsuite/lib/gdb.exp >>>>> @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name >>>>> {location_pattern .*}} { >>>>> global gdb_prompt >>>>> set full_name "continue to breakpoint: $name" >>>>> >>>>> + set re_at_in " (at|in) " <-NEED >>>>> TO FIX TO ALWAYS GIVE local entry point for POWERPC >>>>> ?? >>>>> >>>>> + if { [regexp $re_at_in $location_pattern] } { >>>>> + set re_at_in " " >>>>> + } >>>>> + >>>>> set kfail_pattern "Process record does not support >>>>> instruction 0xfae64 at.*" >>>>> gdb_test_multiple "continue" $full_name { >>>>> - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) >>>>> $location_pattern\r\n$gdb_prompt $" { >>>>> + -re "(?:Breakpoint|Temporary breakpoint) >>>>> .*$re_at_in$location_pattern\r\n$gdb_prompt $" { >>>>> pass $full_name >>>>> } >>>>> -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" >>>>> { >