From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 928FA3858D20 for ; Mon, 11 Mar 2024 19:14:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 928FA3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 928FA3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710184463; cv=none; b=NcahwBggybHFERBeProBMr58tyKWbC0dpK4alSgDxCzsuWYDEFpPsjJN2tvoFj1NF4uK1NJBLC6CuRv5EoLgw8NH1aSlUVTu8LZUZu3b7kV57CmztndmGBuELFzVHEfXsoMaMH3oCnHfQFBlYd401liHdKnTaraaeeUmDRekOgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710184463; c=relaxed/simple; bh=jfbaj0FSO47SYBKd5JJFUVj3EzisYqAMZQNYb/gC0Rg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ZqSm1523tN/4mdilqE5mUeDj5uJzoxNYCgTFDGtnDYdXVWNLygeaatsoXWB0/nmYXO5P0AEKkIim4MdzYtIcBFdoTc9HN46bNo2j0I4uSSolLwJTMg/Y+bbWZrKu1RKWwJiqlbqVlJNkb+MWHOqBMb+uoEDwsLehdgjA0QunrgU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1710184461; bh=jfbaj0FSO47SYBKd5JJFUVj3EzisYqAMZQNYb/gC0Rg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=GtRtxjMS03LWDvleUrcBGtRlkgZZDWtTGm99aXFILbwWXsi2BI5aUCj6RJ+w/lusp gC1cLonlz4MLxoBdaVQeud727YG2yVEj3C7JXjeXXK4Dn1DTTIDg9/QlfqNiz3ORuq bVFWd8YCr7WoEjrJ6y/bAqEU3w+4i/G+zhdr2go0= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 318961E0AC; Mon, 11 Mar 2024 15:14:21 -0400 (EDT) Message-ID: <4c3f986c-a562-4506-b382-c754678abcff@simark.ca> Date: Mon, 11 Mar 2024 15:14:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: GDB 13.2: breakpoint at wrong line after unrelated change Content-Language: fr To: psmith@gnu.org, gdb@sourceware.org References: <7c064cc544bfe453a250ca58b4d5ebd97919178d.camel@gnu.org> From: Simon Marchi In-Reply-To: <7c064cc544bfe453a250ca58b4d5ebd97919178d.camel@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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 List-Id: On 3/11/24 14:28, Paul Smith via Gdb wrote: > Hi all; > > I have an extremely odd error and I'm wondering if it rings any bells > with anyone. If not I'll embark on an effort of upgrading my tools to > see if it's fixed in newer versions and if not trying to file a bug. > > I have a C++ unit test program. This is GNU/Linux 64bit compiled with > GCC 12.3 and I'm using GDB 13.2 to debug it. The error happens > regardless of whether I compile with "-ggdb3 -O0" or with "-ggdb3 -O2". > I haven't tried other optimization levels. > > In the current behavior, I can set a breakpoint at a function and GDB > will stop at the first line of the function; for example: > > class TestClass : public ... { > ... > void breakpointTest(TestData* data) > { > printf("obj = %p\n", data); > } > ... > > If I run: > > (gdb) br TestClass::breakpointTest > > (gdb) run > > then GDB will stop at the printf line, and the "data" variable is set > properly: > > Thread 1 "TestClass" hit Breakpoint 1, TestClass::breakpointTest > (this=0x7ffff2a09a00, data=0x7ffff2aa7000) at TestClass.cpp:100 > 100 printf("obj = %p\n", data); > > > Now if I make a change in my program in a completely different, > irrelevant spot (this change creates a new templated function that uses > Args... and perfect forwarding etc.: it's complex and uses the fmt > library, but it is not being used at all in this function, or even in > this class although it's used in a superclass), then after I do exactly > the same thing above, GDB will stop at the wrong location. Instead of > stopping at line 100 at the first line of the function it stops > "before" the function is entered and the function arguments are not set > yet (in the example below note the values of "this" and "data" are > wrong). > > I have noticed that if I only include the templated function definition > but don't call it, then the problem doesn't happen. When you say that, does it mean that you just define the templated function, or do you manually instantiate it? In other words, does it cause any code to be generated? > I have to use the > templated function somewhere in the translation unit, but it doesn't > have to be anywhere near the function. > > In the failure case if I use "n" to go to the next line, THEN I get to > the first line in the function and everything is set properly. > > Example: > > Thread 1 "TestClass" hit Breakpoint 1, TestClass::breakpointTest > (this=0x0, data=0x21) at TestClass.cpp:98 > 98 void breakpointTest(TestData* data) > > (gdb) n > 100 printf("obj = %p\n", txn); > > (gdb) fr > #0 TestClass::breakpointTest (this=0x7ffff2a09a00, data=0x7ffff2aa7000) > at TestClass.cpp:100 > 100 printf("obj = %p\n", data); > > > Is anyone aware of any issue in GDB, or GCC, where using templated > functions with perfect forwarding or other complex C++ template > features could cause GDB's understanding of the starting line number of > functions to be miscalculated like this? > > Is there a way for me to investigate what information GDB is looking at > to determine where to set breakpoints when given a symbol name like > this? Is this the same info available via addr2line etc.? When placing a breakpoint on a function name like this, on code compiled by gcc/g++, GDB analyzes the prologue and tries to guess at which point the stack for the function is set up and where the location expressions given by the DWARF debug info for the the local variables become meaningful. With optimizations, this can become tricky, but you said it happens with -O0, so let's focus on that. I don't really have an idea of what's happening, but you could try showing what the "disas" command shows after hitting the breakpoint in both cases (the `=>` should show where you are stopped, so where the breakpoint was set). Simon