public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Closing thoughts on RiscV remote protocol
@ 2022-04-22  6:28 Denio, Mike
  0 siblings, 0 replies; only message in thread
From: Denio, Mike @ 2022-04-22  6:28 UTC (permalink / raw)
  To: gdb

Thanks again for all the help on my previous questions. I think I can wind this down now as GDB seems to be all working now. It was actually quite fun and although I'm sure I know only about 10% of GDB now, I was very impressed with what I learned. I have two closing thoughts which I'll list below. Apologies in advance if these are inappropriate due to the 90% of GDB I still don't know. I will shortly take myself off the mailing list. Perhaps I'll get a chance to do more GDB down the road. Right now the project is all remote debug, but there may be other modes eventually.


1. Current thread (or 'scheduler-locking') in all-stop mode

I support all-stop mode now with both setting options of 'scheduler-locking'. I found it slightly odd that GDB doesn't inform the server of the scheduler locking mode and let the server handle it, but rather does it itself by altering the vCont command messages. 

When 'scheduler-locking' is on, GDB will send commands like: 'vCont;c:1' and 'vCont;s:1'. And when the mode is off, the GDB does specify the "current" thread on 'step' with 'vCont;s:1;c', but for continue, it doesn't send 'vCont;c:1;c' just sends 'vCont;c'. Also, for stopping, it doesn't appear to use 'vCont' at all, but just sends a Ctrl-C, whether Ctrl-C was pressed or an 'interrupt' command was issued. 

I think this would work better:
On 'continue' : 'vCont;c:1;c'
On 'interrupt' : 'vCont;t:1;t'

Why? The answer should be obvious for 'interrupt', where the GDB server needs to know the current thread to be reported as stopped, but even for continue, its possible that multiple threads will have hit breakpoints, and the GDB server should prioritize the "current" thread when reporting stop (and only report a different thread if the other thread expressly caused the stop).

There is a hack today for the GDB server to know the current thread. Right now, I believe there are only two ways that the current thread can change. The first is via the 'thread' command, and the second is the result of a stop notification from GDB server. Whenever the thread is changed via the 'thread' command, GDB will send a 'T' command with the new thread. By tracking the 'T' commands, and by being aware of which 'stop' notifications result in a thread change, the GDB server can always be aware of which thread is current, even though it would be cleaner if it were always formally specified in 'vCont' (or through a formalization of the 'T' command). 

The other option would be for GDB server to be told the 'scheduler-locking' mode, making it unnecessary for GDB to send anything but 'vCont;c:1' , 'vCont;s:1', etc.


2. Support for more intelligent hardware breakpoints and single step in non-stop mode

Right now GDB assumes that when hardware breakpoints and hardware single step are supported, that it still must do the following to 'continue' a thread stopped at a break point in non-stop mode:
- stop all threads
- manually remove the break point
- step the 'continue' thread
- replace the break point
- continue all threads

This works, but is obviously slow. I wonder if for platforms that support both hardware break points and hardware single step, would it make sense to for GDB to either have a mode that knows that single step can step through a hardware break point, or an alternative step command that expressly steps through a break point? On a continue, the process would then be:
- Issue 'step through break' on 'continue' thread
- continue the 'continue' thread

Even if the hardware didn't have a single step mode that stepped through a hardware breakpoint, I would think that the GDB server could execute the original process above more efficiently than GDB doing it via individual remote commands (especially given the lengthy stop notification process when there are multiple threads).


I guess that's it. As I said at the top, I think the program actually works quite well, and maybe remote debugging is not that common, but it might be interesting to explore how the GDB server could handle more of the basic processor control operations that the main GDB is doing today ('scheduler-locking' mode, and step through break point being just examples).

Mike



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-04-22  6:28 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-22  6:28 Closing thoughts on RiscV remote protocol Denio, Mike

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).