Re: GDB 13.2: breakpoint at wrong line after unrelated change

[Simon Marchi <simark@simark.ca>]

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