GDB 13.2: breakpoint at wrong line after unrelated change

[Paul Smith]

On Mon, 2024-03-11 at 15:50 -0400, Simon Marchi wrote:
> Ok, so clearly GDB failed to analyze the prologue.  Which is weird
> because the two functions are identical (modulo the addresses).  To
> get to the bottom of this, you (or someone else) would need to debug
> GDB itself.  If you want to do this, I would start at function
> skip_prologue_using_sal, in symtab.c.  Off hand, I don't think we
> have a debug switch to enable logging for prologue skipping.  It
> would be useful to have some here, as we would be able to compare the
> logging shown in both cases.

FYI I have finally gotten back to looking at this.  I've only been at
it for a short time but just for information:

I was able to build GDB 14.2 (latest release) from source and I still
see the issue there.  So I started debugging.

I can tell you that in the "good" binary case I can see that
amd64_tdep.c:amd64_skip_prologue() is invoked which invokes
symtab.c:skip_prologue_using_sal() as you suggested.  In fact, these
methods are called numerous times.

In the "bad" binary case, neither of those methods is called, ever.  I
put a gdb_printf() in both functions and in the "good" binary I see
probably 20 invocations between starting, setting the breakpoint,
running, and exiting: in the "bad" binary zero invocations.  I do see
that we definitely invoke set_gdbarch_skip_prologue() with the amd64
function pointer in both cases, so it's not that.

I'm looking to see where *_skip_prologue() is called from to figure out
where the code paths diverge, just thought I'd send a note to let folks
know that I've not dropped this investigation.