Closed saccharineboi closed 1 year ago
epasveer
commented
1 year ago Interesting.
What compiler/linker are you using?
As a test, can you try creating the breakpoint using "RMB->Create Breakpoint" in the source window (instead of double-clicking on the line number.
I'm curious if the RMB menu shows the correct line number.
saccharineboi
commented
1 year ago What compiler/linker are you using?
GNU GCC 12.2.0, GNU ld (GNU Binutils) 2.39.0
I'm curious if the RMB menu shows the correct line number.
It does show the correct line number, but it puts the breakpoint at a different location.
My guess is that this is due to the fact that the function gets inlined, and GDB cannot figure out where to put the breakpoint since the code that gets inlined in multiple places generates multiple instances of the same assembly output in different memory locations. Basically to put a breakpoint there I would also have to specify the place where the inlined function gets called, but then again seergdb puts a breakpoint at a completely irrelevant site. Shouldn't the correct behavior be asking the user for the calling site of the inlined function? Or maybe be a little smarter and provide all those lines where the inlined function gets called and ask the user to choose one of them? I'm not knowledgeable in GCC so my guess could be completely wrong.
EDIT: I just realized that SeerGDB puts a breakpoint at the for loop so my guess turns out to be irrelevant XD. But I do find it interesting that it manages to put a breakpoint there; does that mean under the hood there are multiple breakpoints at each instance of assembly output?
Anyways, notwithstanding what the GDB does under the hood, this is definitely a bug.
epasveer
commented
1 year ago Thanks for the added information. I will try to replicate the problem with a simpler example. It is odd. I may also be related to the use of templates.
Anyways, notwithstanding what the GDB does under the hood, this is definitely a bug.
Agreed. I will look into it.
Have you tried other debuggers on the same line of code? Might help me to see if it is a Seer or gdb problem.
saccharineboi
commented
1 year ago Have you tried other debuggers on the same line of code?
Just tried with gdb. Yeah, gdb also puts the breakpoint at the "wrong" line. So this seems to be a gdb thing after all. When trying to put a breakpoint at a place that doesn't exist in the build, GDB simply puts the breakpoint somewhere down the source file.
For the following 2 cases _DEBUG is not defined. Here's GDB putting the breakpoint at the "wrong" place:
Here's Seer replicating the GDB output:
Since the culprit is GDB, I don't know what can be done about it. It would be much better for GDB to simply output "this line of code doesn't exist" than to put the breakpoint somewhere else.
BTW I used RMB menu this time but OBS didn't capture it.
Anyways, notwithstanding what the GDB does under the hood, this is definitely a bug
EDIT: The above turns out to be false. It has everything to do with what GDB does under the hood.
epasveer
commented
1 year ago A possibility, albeit a remote one, is you're not recompiling/re-linking your entire source base if you are modifying the inline header file.
epasveer
commented
1 year ago Curious that line 130 is inside a #ifdef _DEBUG
If you're binary doesn't have _DEBUG enabled, then there's no way to set a break point there. gdb is doing the right thing. It's adding a breakpoint to the nearest line after a non-existent line.
saccharineboi
commented
1 year ago If your binary doesn't have _DEBUG enabled, then there's no way to set a break point there. gdb is doing the right thing. It's adding a breakpoint to the nearest line after a non-existent line.
If that's the case then there's no problem with Seer as it's working the way it should.
https://user-images.githubusercontent.com/95090318/198751033-aab32f68-b8bb-4f8c-be31-fc21935edf9d.mp4
Not sure what I'm doing wrong but I'm trying to put a breakpoint just before std::memcpy but instead seer decides to put a breakpoint at a completely different location. Both double-click and adding a breakpoint through context menu results in the same thing.
OS: arch linux with cinnamon desktop CPU: ryzen 3700u Kernel: 6.0.2-zen1-1-zen