Suggestion: there should be a prominent "Stop" button

[ell1e]

I suggest there should be a prominent "Stop" button that unlike the "Interrupt" menu immediately stops the debugged program execution including releasing whatever pause or signal catch from gdb might still be clinging on and reloads the program freshly from disk. Here's my quote from #158 for the rationale:

Often I update the underlying code file(s) once I realize there is some bug, with the intention of then retesting. The exact moment I realize that is usually when SeerGDB just let GDB get to some error condition that either caused execution to hit a breakpoint or SIGABRT and hence it paused, or I manually stepped there with it now paused, and I stared at the output realizing I did something dumb. So at this point, GDB is attached, the program binary was launched but is paused, and now I change the code file and save and type "make" to rebuild the binary, and right after, I hit the new "Reload" for the file in the SeerGDB code view. GDB is still attached and paused at this point.

Now I'm in a bad state where no button really does what I want: because what I would naturally do now is set up the break points again because now I'm looking at the new code, and I fixed something, and I just want to start over and do the whole thing again with new breakpoints and new binary from the new code I'm now looking at. However, GDB is still up and attached with the old binary and sources loaded. So I can't set the breakpoints, because SeerGDB immediately passes them to GDB but based on the new file, but GDB has the old files, and GDB is having none of it and is just doing super weird stuff, changing to random nonsensical lines for the breakpoints, etc. To solve that, the only working button that stops GDB from being stuck in this useless state seems absurdly enough to be the "Run" button, which would also clear out GDB's outdated state, make it reload source files and binary, and finally fix the breakpoints - but the thing is, I don't want to run yet, because I didn't yet set my new breakpoints! Even SeerGDB's "Interrupt" > "SIGKILL" doesn't help, because even when issuing that it seems like GDB doesn't let go of the killed program before I make it resume somehow.

Long story short, I think for longer sessions SeerGBB really could use a prominent "Stop" button. That button should do the equivalent of quitting the program in GDB but not GDB itself, loading the binary in GDB again but without executing GDB's run to launch it, and get me back into a clean stopped state where I can set up breakpoints and then press SeerGDB's "Run" again.

I hope that made sense and is actionable.

[ell1e]

I pondered this some more and I have a suggestion, I hope I didn't observe the following incorrectly:

• When stopped, the purpose of "Run" seems to bring up the dialog and allow me to pick a different binary and then run (although there seems to be a bug where even once the program quits, SeerGDB still think it's running, hence never showing this dialog again but rather asking me if I want to abort and restart even though it's not running). And the purpose of "Start" seems to be to run again without switching binaries. Is that correct?

• When just paused or already running though, "Run" and "Start" seem to do exactly the same, which is abort and start over.

If that is correct, maybe "Start" could instead be replaced with "Stop" when the program is running? That way, the toolbar wouldn't even become more cluttered and yet there would be a good spot for this new button.

[epasveer]

Hi Ellie,

I apologize, I haven't forgotten about this.

Here's a summary. I hope it makes sense. (And I'm open to improving things).

First, starting Seer from the command line:

$ seergdb -s ./hellopoem     # Debug 'hellopoem' and stop in 'main'. You then see the code for 'main'. 
$ seergdb -r ./hellopoem     # Debug 'hellopoem' with no breakpoints. Program starts immediately. You will see no code. Program stops and end or signals.
$ seergdb -r --bl <file> ./hellopoem     # Debug 'hellopoem' with breakpoints from <file>. You will see no code until program encounters breakpoints or encounters signals.
$ seergdb -r --bf <function> ./hellopoem     # Debug 'hellopoem' with breakpoint in <function>. You will see no code until program encounters breakpoints or encounters signals.
$ seergdb -r --bs <source:file> ./hellopoem     # Debug 'hellopoem' with breakpoint at <source:file>. You will see no code until program encounters breakpoints or encounters signals.

Without -s or -r, Seer will always bring up the debug dialog.

$ seergdb ./hellopoem        # Debug 'hellopoem' and brings up debug dialog for last second changes.

[epasveer]

Once your started debugging, the Run and Start button have these behaviors.

Run - Run (or rerun) the program, only stopping on preexisting breakpoints or when signals are encountered.
Start - Run (or rerun) the program, always breaking in "main".

[epasveer]

You are right. Seer always says "the program is already running", even though it isn't. Something for me to fix.

[epasveer]

I suggest there should be a prominent "Stop" button

I really like this idea. I've seen other debuggers with it. I've put in a task with the gdb community to provide a function for it. I'd like to hear what they say. There is a kludgy way I could do it, though.

[epasveer]

Anyway, the "Run", "Start", and eventual "Stop" buttons can be reworked a little.

[ell1e]

Very cool! ❤️ Yeah I assumed all the functionality was already there, but just the choice of button texts usually confuses me a little and I expected one that said "Stop". For what it's worth, I'm a bit slower on feedback sometimes simply because some months I have less to do on the C/C++ side so then I just touch Seer less. It's in any case still an absolutely amazing tool.

[epasveer]

All good. Thanks for your input!

[epasveer]

For my reference.

These 2 threads have a previously proposed "-exec-abort" function for the gdb team.

https://gdb-patches.sourceware.narkive.com/FdZj7eUg/patch-gdb-mi-implement-exec-abort
https://inbox.sourceware.org/gdb-patches/D06EC684.17566%[email protected]/T/#t

[epasveer]

I'm going to combine #162, #192, and #194 together, as they are some what related to the same parts of the code.