#314 quit doesn't properly detach

[Wren Turkal]

The quit command is supposed to detach (and thus continue) the inferior before exiting.

If one wants to disconnect without continuing the inferior, there is also a disconnect command.

I noticed this change: http://openocd.zylin.com/#/c/5600/1

Here's the gdb docs on attach/detach: https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_22.html

Here's the gdb docs on detach/disconnect: https://sourceware.org/gdb/current/onlinedocs/gdb/Connecting.html#Connecting

It would be lovely to have the right semantics so that quiting continues while disconnect does not change the execution state to match these semantics.

[Wren Turkal]

BTW, I am referring to the "quit" and "disconnect" commands of gdb. I don't think I made that very clear.

[Antonio Borneo]

I have made some quick test on what GDB sends with the commands "quit", "detach" and "disconnect". Either by using "-d" flag on OpenOCD side and with command "set debug remote 1" at GDB side.

• "quit": GDB send the low-level packet "$D#44", then it exit
• "detach": GDB send the low-level packet "$D#44" too, but does not exit
• "disconnect": GDB simply closes the TCP connection with OpenOCD and does not exit

There is no way for OpenOCD to discriminate between "quit" and "detach", plus no way to discriminate between "disconnect" and GDB crash or killed or network connection dropped when GDB is running on another PC over the network.

I don't see what can be implemented in OpenOCD to address this ticket.

There is the non-stop mode of GDB, but so far it is not supported by OpenOCD.
In non-stop mode, GDB returns the prompt to the user even when the target is running.
In this case the user can quit GDB and left the target in the current state (e.g. running).

[Andreas Fritiofson]

Isn't that what Wren requests? If we do nothing to the target when the GDB
connection is dropped (killed GDB or lost connection) and resume the target
on the low level packet "$D#44" (detach).

However, it's not strictly specified that the target should resume when
GDB detaches. "Detaching from the target normally resumes its execution,
but the results will depend on your particular remote stub." The
documentation for the "detach" command isn't really relevant since it
doesn't deal with remote targets specifically (it also says that quitting
GDB will kill the running process, not resume it).

On Thu, Aug 19, 2021 at 11:06 AM Antonio Borneo borneoa@users.sourceforge.net wrote:

I have made some quick test on what GDB sends with the commands "quit",
"detach" and "disconnect". Either by using "-d" flag on OpenOCD side and
with command "set debug remote 1" at GDB side.

• "quit": GDB send the low-level packet "$D#44", then it exit * "detach":
  GDB send the low-level packet "$D#44" too, but does not exit
• "disconnect": GDB simply closes the TCP connection with OpenOCD and does
  not exit

There is no way for OpenOCD to discriminate between "quit" and "detach",
plus no way to discriminate between "disconnect" and GDB crash or killed or
network connection dropped when GDB is running on another PC over the
network.

I don't see what can be implemented in OpenOCD to address this ticket.

There is the non-stop mode of GDB, but so far it is not supported by
OpenOCD.
In non-stop mode, GDB returns the prompt to the user even when the target
is running.
In this case the user can quit GDB and left the target in the current
state (e.g. running).

---

• [tickets:#314] https://sourceforge.net/p/openocd/tickets/314/ quit
  doesn't properly detach*

Status: new
Milestone: 0.11.0
Created: Thu Aug 19, 2021 05:02 AM UTC by Wren Turkal
Last Updated: Thu Aug 19, 2021 05:32 AM UTC
Owner: nobody

The quit command is supposed to detach (and thus continue) the inferior
before exiting.

If one wants to disconnect without continuing the inferior, there is also
a disconnect command.

I noticed this change: http://openocd.zylin.com/#/c/5600/1

Here's the gdb docs on attach/detach:
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_22.html

Here's the gdb docs on detach/disconnect:
https://sourceware.org/gdb/current/onlinedocs/gdb/Connecting.html#Connecting

It would be lovely to have the right semantics so that quiting continues
while disconnect does not change the execution state to match these
semantics.

---

Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings
at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this
is a mailing list, you can unsubscribe from the mailing list.

[Antonio Borneo]

You think in OpenOCD we could:

• discriminate between GDB "quit"/"detach" (reception of "$D#44") and GDB "disconnect"/crash (TCP link lost):
• trigger two independent event handler "gdb-detach" and "gdb-disconnect" (today the two cases falls in the same "gdb-detach")
• as in http://openocd.zylin.com/#/c/5600/ use a default "gdb-detach" that runs "resume"
• keep empty the default "gdb-disconnect", or with a silly "echo disconnected"
  ?

[Wren Turkal]

It seems to me that a disconnection whether by the command or by a crash of gdb should not change exec state. That seems totally logical to me. That way a crash of gdb doesn't prevent reattaching and continuing to debug.

With quit though, the explicit detach is intended to restart the program so that it isn't paused after exiting the debugger.

The only way that I have found currently to end gdb with the program running is to continue execution in gdb. Then, go to another terminal and kill -9 the gdb process. This is not great. I would love to be able to choose which to do by only interacting with gdb in a normal way. Having to kill the process from another terminal is annoying, but it also limits the ability to script certain actions within gdb.