Re: GDB 13.2: breakpoint at wrong line after unrelated change
Paul Smith via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Organization | GNU's Not UNIX! |
| Message-ID | <[email protected]> |
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.