From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) by sourceware.org (Postfix) with ESMTPS id 2389C3858401 for ; Mon, 15 Aug 2022 19:31:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2389C3858401 Received: by mail-vs1-xe30.google.com with SMTP id c3so8104018vsc.6 for ; Mon, 15 Aug 2022 12:31:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc; bh=+EKhprz15GwZDBj77G49qy5ARPbjFfK/AlYJAKZ6e5M=; b=3uTa7Ia34NMRDBKO1pKZag8OPNY08aLYi2zXflOfXvUQ0yPUHLoKT9m1ChEIgB6cij gOHcTDecWA3NiNJ7npwQ/0JkormLsENjD/ZJZ9Z8U+6xRDxZuyhBRj5WNE3QCuluzoU8 4c71spDfMxb2HebbIyt7ZD0FXDv+10bv0iBkwCSH0mJKOMKbmmgNMv2xvu0VWAtgkbWX aOmbXcpYGbMxwOFVi2ckSHqca4vtigjcGN9Q4rAzVV3oxMLQs4MDUCfGes4NmqeRPLhF IKtwcbZ4iGojJHEjQ2VD0TkfdBus48xIYRPvuNzbguucxL00UsE1BBgscMpwmQIn1pB9 27gQ== X-Gm-Message-State: ACgBeo0kaoOx9tc2wedZ/lkqcqsH+y8bWYNjv/hTF22xZBkiZ1AmhcQS KzqRCXamBvFCpJzx/H+4W8iUzw== X-Google-Smtp-Source: AA6agR6aGUu9CfWDtbXjN92zxDs2azH2hWUdWFF0arQpIy73pBEp/FgNtdjDoent1jp/HrnEHIjXeg== X-Received: by 2002:a05:6102:a8d:b0:357:ffc4:83c2 with SMTP id n13-20020a0561020a8d00b00357ffc483c2mr7003172vsg.23.1660591877518; Mon, 15 Aug 2022 12:31:17 -0700 (PDT) Received: from localhost ([2804:14c:8780:89d8:2a29:b3e2:94f5:87d7]) by smtp.gmail.com with ESMTPSA id f83-20020a1f3856000000b003763ad7ed5bsm7580903vka.6.2022.08.15.12.31.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 12:31:16 -0700 (PDT) References: <20220811115809.GA19509@delia> <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> <10b3195562b41db8f77d3c0cbd984d0da270190e.camel@vnet.ibm.com> User-agent: mu4e 1.8.8; emacs 28.1 From: Thiago Jung Bauermann To: will schmidt Cc: Carl Love , Luis Machado , Tom de Vries , Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp In-reply-to: <10b3195562b41db8f77d3c0cbd984d0da270190e.camel@vnet.ibm.com> Date: Mon, 15 Aug 2022 19:31:14 +0000 Message-ID: <87r11h483h.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Mon, 15 Aug 2022 19:31:22 -0000 Hello, will schmidt via Gdb-patches writes: > 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. [ ] >> 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. > > 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. > > The patch should probably be reverted, but I defer to others if I've > misunderstood part of this issue.. Is it possible to force the compiler to use the global entry point? Perhaps by calling the function via a function pointer rather than as a regular function call? That would allow preserving the change to the testcase and making it work on ppc64le. -- Thiago