question about vCont behavior

[daniel5151]

I am here not directly with this issue, but with vCont in general, I am having an issue with "next" in gdb, when nexting over functions with deep inner loops. Without vCont, it starts stepping and sits there spinning for extremely long periods of time (minutes). When I just want to go "next".

But if I stub in vCont, say by replying with vCont;c;C;s;S, and then I "next" in gdb, I Get vCont;s:1;c#

I can't figure out what GDB is trying to get me to do there. Some people online are saying that's a single step, but if I do single step with that, it just super spins. It doesn't make sense to me... How does gdb avoid spending minutes stepping through with other gdb servers?

If I interpret vCont;s:1;c as step once then continue, it runs for a bit then gdb breaks execution later.
If I interpret vCont;s:1;c as single-step, the behavior is no different than if I make no changes, and gdb just spins...

Originally posted by @cnlohr in #152 (comment)

[daniel5151]

Sure, I don't mind offering some thoughts here, even if this isn't strictly gdbstub related.

From my experience, GDB is pretty inconsistent in how it models step, continue, and breakpoint semantics across different targets. e.g: a packet sequence in response to a high-level next command when debugging a x86 target may vary wildly vs. doing the same thing on ARM. So, you'll certainly want to keep that in mind as you're digging into the semantics you're seeing here. What arch are you trying to debug?

My interpretation of vCont;s:1;c, which matches what gdbstub implements, is "single-step thread with ID 1, and let all other threads on the system run freely". See the docs at https://sourceware.org/gdb/current/onlinedocs/gdb.html/Packets.html

Another thing you should do is enable packet debugging on the GDB-side (and if possible, on your stub side), to see what sorts of packets (if any) are flying around while you're "super spinning". From the GDB-side, this can be done by invoking set debug remote 1.

Hope some of these thoughts / observations are useful. Implementing a gdbstub from scratch is, unfortunately, a painful experience... and one that I hope gdbstub as a library makes easier for folks, letting them focus on the nuts-and-bolts of their particular integration, vs. wrestling with the questionably-defined and archaic GDB RSP.

---

P.S: I'm actually a long-time subscriber of yours on YouTube, and love all the projects you hack on!

[cnlohr]

That makes me really sad that the behavior is inconsistent. These are all very interesting points. I have been enabling packet debugging this whole time, just have had a lot of trouble regardless.

Thank you for the kind words, as well! I am really starting to do my best to support a sort of minimal-SDK environment for chips, starting with the ch32v-series parts. And while I only use printf debugging a lot of other people use gdb. It was really easy to implement, except for this stepping behavior. It has absolutely driven me up a wall.

In retrospect, it is starting to look like I should not have added vCont - it's just not clear at all me to me why the bevahior is so hard to get right.

[daniel5151]

One other thing I'll note (that you may / may not already know) is that the high-level next and step commands may not always correspond to a single step / continue command, and may set up "implicit breakpoints" in your code.

i.e: if a single LOC corresponds to >1 asm instruction, gdb may set a breakpoint at the start of the next logical LOC, trigger a continue request, and rely that the guest hits and reports the breakpoint back to the client once it has executed >1 asm instructions.

Moreover, depending on the target, these breakpoints may be set via the breakpoint RSP packet (i.e: z/Z), but if you didn't report support for them, the GDB client might instead issue memory read/write commands to manually rewrite the instruction stream in order to insert a software breakpoint!

With that in mind - you should def make sure you've got solid breakpoint handling in place if you're intending to use "high-level" flow control commands in GDB. If not, you may need to stick to using plain 'ol stepi and continue, which should map 1:1 to the underlying GDB RSP packets (I say should, since again, behavior varies a lot by target, ugh)

[cnlohr]

I would love it if they would setup implicit breakpoints... But, it does not appear that that was happening. If I set actual breakpoints on lines, they are totally set. So I assume GDB knows it's allowed to use z/Z. Is there somewhere else I need to report their existence?

Side-note: How do I tell gdb z/Z is supported?

[daniel5151]

Side-note: How do I tell gdb z/Z is supported?

https://github.com/daniel5151/gdbstub/blob/master/src/stub/core_impl/base.rs#L163

[cnlohr]

So, I advertise as hwbreak+, because I want to get Z/z commands. But, they are ultimately swbreak+ breakpoints. Is there any issue with that?

[daniel5151]

Unclear? I would suggest being honest, and reporting swbreak+ instead / as well as hwbreak+.

I'll note that at various points in gdbstub's development, I simply resolved to spelunking through the gdb source code to try and figure out what it was trying to do, especially when debugging weird target-specific behavior. You may want to bite the bullet and give that a shot yourself.

[cnlohr]

Will test it.

[cnlohr]

There is no discernible difference.