Allow re-running a program

[bonefish]

When the debugged program quits, it is sometimes rather inconvenient that Debugger immediately wants to quit as well. In some cases the program quitting was unexpected (e.g. an uncaught exception or exit() while stepping over a function call). In such cases one often wants to set a breakpoint at the last location and re-run the program. Since the quit alert is modal, one is forced to quit, restart debugger, find the code location, set the breakpoint, and run again. This is rather inconvenient.

A somewhat similar situation is when one has stepped over a function call that did something unexpected and one wants to run the program again, this time stepping into the function. This is not quite as inconvenient, since one can set the breakpoint first, then quit and restart debugger, and run the program again, but a few user actions could be saved anyway.

In IDEs and other debuggers one usually has a mode where the program doesn't run/isn't loaded (yet), but one can still set breakpoints. That would be nice for Debugger as well.

[anevilyak]

A potential problem/caveat with regards to this one: currently, the strategy I'm following is to have the TeamDebugger instance get passed the command line arguments used to start it such that it can preserve them. Then, if the team quits, the user is asked if s/he'd like to do nothing, quit, or restart the team in question. If so, the aforementioned command line arguments are used to reconstitute a fresh "start new team" request similar to what's done via the Teams Window, or by passing the args to the Debugger command line directly.

However, in the case where we're asked to attach to an existing team, this might not be reliably possible, as the kernel only preserves the first 64 characters of the command line args. Depending on the length of the path and/or arguments, this might not necessarily be sufficient, in which case the restart will either outright fail, or possibly start the team with incomplete/incorrect arguments. Is there a way around that, or is that simply something we'd have to live with for now, ergo detect that case and don't offer the restart option if so?

[axeld]

I see two and a half way around that: 1) Implement proper argument retrieval from the kernel. IIRC they are stored there completely, anyway, already. 2) Ignore the command line options of attached teams, or don't even offer the option of restarting those. Alternatively, one could open a window where you can alter the command line for the next run.

[anevilyak]

Replying to axeld:

I see two and a half way around that: 1) Implement proper argument retrieval from the kernel. IIRC they are stored there completely, anyway, already.

I'd initially hoped this was just an ABI compatibility limitation due to the definition of the team_info struct, but unless I'm drastically misunderstanding the code, ​http://haiku.it.su.se:8180/source/xref/headers/private/kernel/thread_types.h#395 suggests that the kernel-side Team object also only preserves the first 64 characters, so it'd seem handling this properly would require more than just an alternative syscall for argument retrieval.

2) Ignore the command line options of attached teams, or don't even offer the option of restarting those. Alternatively, one could open a window where you can alter the command line for the next run.

Not offering the option was what I was leaning towards initially. Opinions welcome.

[bonefish]

I think not offering the option in that case is OK. The kernel args as they are stored aren't really useful for anything, since IIRC, besides that they are truncated, they are just a concatenation of the argument vector without any escaping of whitespace. So, even if they fit the 64 bytes it is not generally possible to reconstruct the argument vector.

[anevilyak]

Mostly implemented in hrev45722. The dialog box now presents options to restart the team, quit, or do nothing. In the latter case, some more work is needed though, as one currently can't set breakpoints with it, since the debugger interface obviously no longer has a nub to talk to, and we're presently completely reliant on getting the corresponding events back to actually set/store the breakpoints in the manager. Need to see what I can come up with on that front, and leaving ticket open until then.

[anevilyak]

Remaining part taken care of in hrev45728. One can now install new breakpoints after picking the aforementioned "do nothing" option, and then request a restart via the Team menu to have them take effect on the next run.