From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id CB4843858D1E for ; Thu, 1 Sep 2022 14:40:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB4843858D1E Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0F72320151; Thu, 1 Sep 2022 14:40:18 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id DC65013A79; Thu, 1 Sep 2022 14:40:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 4ahiNFHEEGMBYwAAMHmgww (envelope-from ); Thu, 01 Sep 2022 14:40:17 +0000 Message-ID: <61b1893d-144b-7627-d5c3-50d4bdafdc84@suse.de> Date: Thu, 1 Sep 2022 16:40:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp Content-Language: en-US To: Ulrich Weigand , "gdb-patches@sourceware.org" , "luis.machado@arm.com" , "cel@us.ibm.com" References: <20220811115809.GA19509@delia> <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Thu, 01 Sep 2022 14:40:20 -0000 On 8/17/22 14:01, Ulrich Weigand wrote: > Carl Love wrote: > >> 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 > The local enty point is actually here: >> 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 > > Not here. This point might be the end of the prologue, which is a > separate question from the local vs. global entry point issue. > >> Perhaps Ulrich has some ideas??? > > This: > + gdb_breakpoint *$func > is nearly always wrong, and test cases shouldn't be using it. > Ack, I've posted a fix that doesn't use that construct anymore. > I know that in the past, this construct was sometimes used with an > intended meaning of "set a breakpoint at the start of a function > without skipping the prologue", but it does *not* actually mean that. > > The "*" operator tells the breakpoint logic to set a breakpoint on an > absolute address. If followed by a symbol, that symbol's value is used > as that absolute address. Now, on many platform, that symbol value > matches the address of the first instruction of a function, so the > "break *func" does more or less what's intended above. > > But there are other platforms where this is not true, and the > relationship between the function symbol value and the address of the > first executed instruction is more complex. This specifically applies > to targets that implement gdbarch_deprecated_function_start_offset > and/or gdbarch_skip_entrypoint. (ppc64le uses the latter.) > I think we could add a note to the docs explaining this. > Note that these are *independent* of prologue skipping, and on > platforms where it matters, they have to be used even when avoiding > prologue skipping, in order to correctly find the first instruction of > a function to set a breakpoint on. "break *func" ignores this, > leading to failures on such platforms. > > > As I said initially, I think this construct should never be used in > test cases (at least not in scenerios where it is intended to set a > breakpoint that will actually be hit). > > For this specific test, if the underlying problem is a bug in some > architecture's prologue parser, then ideally this bug simply should be > fixed. Yes, it should, and a test-case should be added for that. In this test-case, we try to test a feature that has nothing to do with architecture-specific prologue skipping, so given that there can be problems with it on various targets, the test-case should simply skip it. Thanks, - Tom > If we need to actually avoid prologue skipping for some real > underlying reason, we should use a way that still handles function > start offsets and entrypoint skipping. For example, in a function with > debug info including valid location lists, GDB will always avoid > prologue skipping. We could also think of adding an explicit linespec > modifier that would allow to explicitly set a breakpoint on the first > instruction of a function without skipping prologue ... > > > Bye, > Ulrich >