Closed ell1e closed 10 months ago
I noticed this too a couple weeks ago, It used to work. I must have broken it along the way.
I'll check into it.
For what it's worth, sometimes it works now, but often it just doesn't and either nothing shows on hover, or it shows something like 0xefaf294
(some random address) for e.g. an integer where the "Locals" tab clearly shows some value like 2
which doesn't seem to make too much sense to me. The "Locals" tab on the other hand seems to be very reliable, so if it could just behave a bit more like that one, then everything would be fine.
I think I found why it often doesn't work:
The most common problem case seems to be when I'm hovering variables in a file in a function that is part of the current paused call stack, but not the frame selected in "Frames". I don't know gdb well enough, but if possible seer should maybe e.g. switch gdb to the frame this function is in and immediately back to supply these hover values if needed. (Since I think it's not that obvious or intuitive that you would need to manually always switch the frame in "Frames" to match the code you're currently looking at, just to make sure that hovering values works. When clearly a line is yellow marked as part of the stack and you're hovering stuff around it, I think the expectation is that it "just works", no matter how that happens behind the scenes.)
What you surmize is correct. You need to set the stack frame first for the source file you are looking at.
I'm not sure about other gui debuggers -- if they can handle it the way you're suggesting. I'll check them. If they can, I should be able to.
The most common problem case seems to be when I'm hovering variables in a file in a function that is part of the current paused call stack, but not the frame selected in "Frames".
So I tried a comercial Linux debugger, and it has the same problem. It hovered with an empty tooltip.
You just need to select the proper frame first. Seer (really gdb) can't figure out the frame by which source file is put to the top.
I'll try the DDD debugger later to see what it does.
One thing the comercial debugger does is:
This last one I can likely add to Seer.
I think in Visual Studio the hovering "just worked", but maybe I'm remembering wrong. I haven't touched that one in a while. I assume the difficulty is knowing what function a hovered name belongs to especially if that variable name is used in multiple functions in the stacktrace, with no knowledge of the code. But at least if the stack trace only enters a file in one frame it feels like it would be trivial (by just finding which single frame is in a function that is in this one file), as well as when a variable name only appears in one of the frames locally and never as global symbol (by just getting the locals of all frames and then picking the only frame that has it), but I guess just covering these two cases would be a very unsatisfyingly limited use.
Even the DDD debugger doesn't support what you're asking for. I don't see how it can be done.
However, I'm finding when the correct stack frame is selected, Seer is still having problems showing the variable value in a tooltip.
So, I'll use this task to:
Hovering a variable name in the center source code view when in a paused state should show its current value in a popup, if it was set. This is one of the main benefits of graphical debuggers in my opinion, but it seems like seer 2.2 can't seem to do this yet so I think it would be a great addition.
Just as a mental model and for efficiency, that I can't just point a mouse at some thing in my code and just see what it's set to right now, and I'm forced to look in multiple places, it just feels very cumbersome and dated. (And that despite an otherwise modern looking and useful UI.)
Tested and feature found to be not present in seergdb version: 2.2