From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150081.outbound.protection.outlook.com [40.107.15.81]) by sourceware.org (Postfix) with ESMTPS id 57DE7385840C for ; Fri, 23 Sep 2022 10:56:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57DE7385840C ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=iR9ApM6GL3+dVMjbiyk18NyRBPf78QvNj3O703+hmVjHSQiGI4gVMZO5ebPi9NdWbCBnu+25KG1lVcKrIji0g/Gud8uQCaxvdY8Cwndn9PkZX2yFVcwFzeRHEABqz5DeA7N6LYtpEMvpiW7HFtJ+TNrkJGfVZv7lXrO64UiagiER0xkqrgyaooGhh17cfTTPFFhPgUdFi4zZVBcxGRbI5IJNKOqi+Td5+tsydYRhXjTn6BqWxeNhTnbm0AdisE4qB4h7IstZKHFTIIDqI1NuRSeXwzmhdb2yG8cXt3D8eyAQEG3+LFBCvz9p5dipaY9V2GyWFVborV2LTAEyEkIF/A== 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=dxdRLitwRnHZUJFeu68dAVuT1Mk/3qqpX8f44aZcqBk=; b=ajNi74uEabGgAytL7iHxGfM9akEyUsr9CGx1O+g/6ZdSK0A19IYvSsymIn5nQGlmcmQkvlcQvFbCsabi+SluYOdb1RHXF31oelc50FS2O+Xetbms9Qfg3leGIdtHYtFWh/u9PmFHfPj2KTHwBkdXqf1tmlwy2bJlccznTjEbTrIcfqzcPRcneGMhC0p0hLZktE3FXHLdKoFdzFkChVcf/Qv0H1653iLRmggNT5g3TlKcJENsraej/UzfvjJ4eUuLbeVJCyJzvcCX/+ntXbvKzgjnzLxp5wWblUJeYrSwEZD1jg0QfqZoQ61eYmID7KMCTNLD4hPAqvUKqRGhTk0+UQ== 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 AM7PR02CA0015.eurprd02.prod.outlook.com (2603:10a6:20b:100::25) by AS8PR08MB9431.eurprd08.prod.outlook.com (2603:10a6:20b:5ed::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.19; Fri, 23 Sep 2022 10:56:48 +0000 Received: from AM7EUR03FT013.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:100:cafe::d7) by AM7PR02CA0015.outlook.office365.com (2603:10a6:20b:100::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5588.18 via Frontend Transport; Fri, 23 Sep 2022 10:56:48 +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 AM7EUR03FT013.mail.protection.outlook.com (100.127.140.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14 via Frontend Transport; Fri, 23 Sep 2022 10:56:48 +0000 Received: ("Tessian outbound 8ec96648b960:v124"); Fri, 23 Sep 2022 10:56:48 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 378319e0cffbb2e9 X-CR-MTA-TID: 64aa7808 Received: from 6c0ca25e681e.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id CD363D26-9914-436B-9004-27A873D219A0.1; Fri, 23 Sep 2022 10:56:41 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6c0ca25e681e.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 23 Sep 2022 10:56:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gS/uDcbuAACuK2lxbyBx4uEo7+snWlkjmSu9jmcEk8jm4/Z7sfkMe9krUaVaHDiZxPmndTs/vLkxKSs5BEs6Y6ApgJ5pOFoAuEZdDanHezrnd7bbYVuJ+SMkZ+2+vecr+ViAWb/oOBe3pI6wm4PdV+Ox/Tqv0Xv5UwgXml/Uzhss/mzK4zgEBOI697byX9wzCCFc+YEdghGxTgOsD6V9W/+/M+CA7eQSq4GViGvh4bkSJos8G78spemK4eVykaE4z2O+jgqH3dt63ta13FvFV1cSUohPXqwflwZ64uJYoh7uh4nTLYNigd4nmkLa0Qt0uvSt7hvPqAnDkQ3poYT6aw== 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=dxdRLitwRnHZUJFeu68dAVuT1Mk/3qqpX8f44aZcqBk=; b=VqnIyJELXCzv3Zkj8vAT9FIgs+Qm5/Y+85RF6pdS0yCxNOR3OjKEoYiNX/A+nagb55mV5WJQChaTRQNaZIYvI8vK1Xf+0V+CRvmQZgA7Qq6dOBt33ZaWJH5Ghdif4CtPqa9lEHkM8h5LM+HjIvZ20Kv+q2O0z86v5oi3yMeHhaA88UQmcMHqX/DtyK90LTxGKVeXd8+Y/TzxQYtaAO/WofGJ9iGOXXjumDmIM5OZfwQgflAfT/fKgix8er3hVf2ZN856z2nzgSryR0daWuSQKcoDhbCOlImMKyxtca6AwYPKpxUgsD8uMmKvkgSjh+oFn9yQ76spS7iuTy3hNMb58g== 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 PR3PR08MB5564.eurprd08.prod.outlook.com (2603:10a6:102:87::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.20; Fri, 23 Sep 2022 10:56:39 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094%5]) with mapi id 15.20.5654.016; Fri, 23 Sep 2022 10:56:38 +0000 Message-ID: <7700d3ed-79f2-83c7-0256-22146d94dab1@arm.com> Date: Fri, 23 Sep 2022 11:56:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp Content-Language: en-US To: Carl Love , "gdb-patches@sourceware.org" Cc: Ulrich Weigand , Pedro Alves , Pedro Alves References: <1398bb10-2ed9-c074-0627-43d7e2feddea@arm.com> From: Luis Machado In-Reply-To: <1398bb10-2ed9-c074-0627-43d7e2feddea@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0015.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::20) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|PR3PR08MB5564:EE_|AM7EUR03FT013:EE_|AS8PR08MB9431:EE_ X-MS-Office365-Filtering-Correlation-Id: 728620f7-f440-41f2-67d8-08da9d525048 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: 7+Ux0StKUHNbJa1jogHLDwx2CA0ByC2orYcihvfh6dTy3ovdjHjOrxkYgspa5OqAfF76ZaPCRI6q7J+lfSSvbIylY3wqKcMIS5DmcqsFLwAj6FchosH5t9p1rKGCm5rn3N7T35GNO2Fiivk53lwfDkHbBvPIeuOTZAzlBihNMI4F62KBym8Oc0m5eRK8zecdaAqwaCSL7YOXrry0IZraGOoWIUKQdBe4Av/NBoY5bsgotmmhw5TGWV2Y9CKzO4cyIjMTUv9n07vXdnRj+lKYgshDYMWBglhnmZbGr2C8PCAbo21EB61RhefqTxiz3Jv3iO8Mk5FZtDZ9La4BqzG0ZCEXVwigY+DTyVgmNh2EBTrl+9mzni2D0ZfrRhDNP2Rf2BszfuMsSm3lWdgUnxgllSPJN9jNfV2AkicbLf8hvyEauSYjKOlCUSiwvH8B9yVgu8c3fKxetTY3I1r/wd8dVPaU4hKd7/D/D6Evs5B3YDx4BivCoiKL58tUs1JJ17j00dsUOGuAk3MKR3FLxt/0fq6Vido0ZuLjtS3nb+GxhbGdshrayakNdazSPlo/h3QSCOAGuQpeUYWhXRq1NY232g1ljiaG5Ya3blx3L+6t76agvoQ/wqsBOaqWhsG2mZ+goJ/wMGS87z6459+wUFBDNgGQVOgFawVIiI98IaDAFh351wxCV12ylEV6WiB4D9W5Gn8AOQbAsDVHt+HqEI9IvQwTSokYXRBOxGkPHI/sNWfe62b4lUqnviEwzPqoP3LEByuRqu9w+gYQVadSwa47Ap0CvkMXp0DPY5Bgk1DUR4bFCG3UdsFLd4pC2FHQ/auk1mt8+KgRm1fkZQl7ep0VdA== 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:(13230022)(4636009)(396003)(366004)(136003)(376002)(346002)(39860400002)(451199015)(38100700002)(44832011)(31686004)(478600001)(6486002)(31696002)(2616005)(66476007)(83380400001)(66556008)(86362001)(186003)(66946007)(4326008)(26005)(6512007)(110136005)(6506007)(53546011)(54906003)(2906002)(36756003)(5660300002)(8936002)(84970400001)(8676002)(41300700001)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5564 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: AM7EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 645abb61-2e80-4f0d-10e2-08da9d524a69 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gtzYTgDTg+mJ8c9bxfEMm7JGU+cDaObBLBG+sWV+vXsrX284Hf1qMTRsoMMDj+1E8kBYBPPk2qsdS1bMy/gPt9cvRforskmnMYtP8eMURKWJyMJCt8qQQG1jeGjVUV2UuZlYS3BLQyD/U6dvoqbDfN0r5KCGEimywz5FN1FdUrIpmIQb+BSr0LfT3zPIu06fL4mpjkxSRvz/gnhnZdJuTYds7dGfDTzwdlK3r7gcWEHHXyKYGKw+YJ7QnqqvEYVf0Eggx68V13ybqCVK1S+YeEwabEUjaVokBIsELySKho3zdqf73ClKkpVkMrhej18/v8cy4zUAig9OnOAcvgAsNya25XRWfSE8h+xq1NQEIrROupaLK83mFdBFRZGQ/BhhBS/6N3gUpco7T1oUvGBRqYhF7sf96wY1qKR0MafrSPUbu9pkxNBMON2w3Kxy8IPlWka3aBDxqxHQAi4pkRCIKbQr3r7MWdUjoF9pJnnMi0R16aVpBechOWqanCbXCeMu0GLDehgcPsOEeAVpLj4Xd4pbslghohSwKo/n5UpsJ1DZtUwKs9AmQJS9idKPVZsshuaQ5/bCVC/usnhXHDZ3KJ74Qavt6FAH6DHascEaAX6w50MlVrFcOxDV/krnABmLAMn0d0BrwnMn1VJX9KRng7oqzq89F0ztyE+DlNYH9Vxrt3NIWyo+q9X1x/xIp3EBkSt1k0kQ94ZWgYFuUZ3eyFc4StZvfJv+rQuGMdu7/QJmiHxdZJDuJPBsx70A1YS4Hbq6eYINM9Gi2r3XCsxL5v0iwUm4Sgq+YfBwKUa8sCc5UJZ59HI9iAO2UKkNnOSoqCFXTQ9pEeeAkQBHWD3skw== 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:(13230022)(4636009)(396003)(39860400002)(136003)(376002)(346002)(451199015)(40470700004)(46966006)(36840700001)(36860700001)(40460700003)(82310400005)(356005)(86362001)(31696002)(81166007)(2906002)(82740400003)(6506007)(110136005)(2616005)(107886003)(53546011)(316002)(6512007)(54906003)(40480700001)(41300700001)(8676002)(4326008)(26005)(478600001)(6486002)(8936002)(44832011)(5660300002)(186003)(47076005)(336012)(70206006)(70586007)(83380400001)(31686004)(36756003)(84970400001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2022 10:56:48.5522 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 728620f7-f440-41f2-67d8-08da9d525048 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: AM7EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9431 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, KAM_DMARC_NONE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 23 Sep 2022 10:56:55 -0000 On 9/23/22 11:48, Luis Machado via Gdb-patches wrote: > Hi Carl, > > gdbarch has a hook to adjust the breakpoint address (gdbarch_adjust_breakpoint_address). Can this be used to bend commands > like "b *func" so they behave the same as other architectures? > > Alternatively, you may need to conditionally (for powerpc) walk through instructions and locate > the correct address for the breakpoint. Also, "break *func" is a fairly common command for users to issue when they want to stop exactly at the address of func. Even though this is not technically always true, I think it is still pretty intuitive to expect that it will work. Should GDB issue a warning of some kind so users are aware this doesn't work for power? It would also help you track down testcases that expect this to work, and maybe some others that just happen to work but may break in the future. > > On 9/22/22 19:23, Carl Love via Gdb-patches wrote: >> GDB community: >> >> There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and >> gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar >> reasons on PowerPC.  It appears to me that the issues are with the >> tests and not with gdb itself. Both tests set breakpoints on *func >> where func is a function in the source file.  This is the fundamental >> issue with both tests. >> >> The test gdb.reverse/finish-reverse-bkpt.exp has the comment: >> >>     gdb_test "tbreak void_func" \ >>         "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ >>         "set breakpoint on void_func" >>     gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" >> >>     # We stop at the brekapoint on void_func, but breakpoint on >>     # *void_func will be set at the same place if function void_func doesn't >>     # have prologue.  One step forward to avoid this. >>     gdb_test "si" >> >>     gdb_test "break \*void_func" \ >>         "Breakpoint $decimal at .*" \ >>         "set breakpoint at void_func's entry" >> >> The comment about break point on void_func and breakpoint on *void_func >> being the same if there is no prolong is not true for all >> architectures.  Specifically PowerPC uses local and global entry >> points.  The statement "break *foo" sets the breakpoint at the address >> of the first instruction in the function where as "break foo" sets the >> breakpoint at the beginning of the function, i.e. after the prolog >> following the local entry point.  Specifically for this test the >> PowerPC assembly code is as follows: >> >>     void void_func () >>     { >>         1000068c:   02 10 40 3c     lis     r2,4098                <-global entry point, >>                                                                      location of break *void_func >>         10000690:   00 7f 42 38     addi    r2,r2,32512 >>         10000694:   f8 ff e1 fb     std     r31,-8(r1)             <-local entry point >>         10000698:   d1 ff 21 f8     stdu    r1,-48(r1)             <-prolog >>         1000069c:   78 0b 3f 7c     mr      r31,r1                 <-prolog >>       void_test = 1;                /* VOID FUNC */ >>         100006a0:   00 00 00 60     nop                            <- location of break void_func >>         100006a4:   58 81 22 39     addi    r9,r2,-32424 >>         100006a8:   01 00 40 39     li      r10,1 >>         .... >> >> The test fails on PowerPC because the reverse execution never hits the >> breakpoint at *void_func because the function is called using the local >> entry point.  Thus gdb returns to the caller after it reaches the local >> entry point at address 10000694.  It does not continue executing back >> to the global entry point.  The global entry point is only used in >> special cases when the Table of Contents (TOC) pointer is not already >> setup in r2. >> >> The question is how to fix the test in general? >> >> 1) Changing the breakpoint on *void_func to void_func will cause both >> breakpoints to be the same regardless if there is a prolog.  That >> change would seem to invalidate the point of the test? >> >> 2) Disable the test for architectures where the assumption breakpoint >> on foo and breakpoint on *foo is the same except for a prolog.  The >> downside is we are missing testing of some gdb functionality. >> >> Is there another way to fix this test to run correctly on PowerPC? >> >> >> The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because >> it does a break on *callee.  Specifically, >> >>     set lineno [gdb_get_line_number "STEP INTO THIS CALL"] >>     gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" >> >>     gdb_test "b \*callee" "" "set breakpoint at callee's entry" >> >>     set bpnum [get_integer_valueof "\$bpnum" 0] >>     gdb_test "reverse-next" \ >>         "Breakpoint $bpnum, callee.*" \ >>         "reverse-next over call trips user breakpoint at function entry" >> >>     gdb_test "up" \ >>         ".*NEXT OVER THIS CALL.*" \ >>         "stopped at the right callee call" >> >> In this case, it looks to me like changing the gdb_test to callee >> instead of *callee doesn't break the point of the test.  Making the >> change on PowerPC fixes the test. >> >> Does anyone see any issues with changing the breakpoint from *callee to >> calle for this test? >> >> Thanks for the input and help fixing these tests on PowerPC. >> >>                                     Carl Love >> >