[mips] "unexpected packet" packet on single step about gdbstub

[daniel5151]

To use RUST_LOG, you need to have a log/tracing compatible logger initialized. I should probably update the issue template to mention that (I just assume you do, since these tend to be the "go-to" logging infrastructures in the Rust ecosystem). I personally use https://github.com/seanmonstar/pretty-env-logger, but you can use whichever one you like!

Totally happy to dig into things some more once we've got those trace logs!

[lemmy-64]

Thanks! Please see attached for the log. The last few lines are:

TRACE gdbstub::protocol::recv_packet > <-- $m8002bf80,40#f7
TRACE gdbstub::protocol::response_writer > --> $3000c18f4000c1af4800c18f080041ac4400c18f040041ac4000c18f000041acefaf0008000000001000c28f02000124080041a0efaf0008000000002800c193#38
TRACE gdbstub::protocol::recv_packet > <-- $m8002bbac,4#1f
TRACE gdbstub::protocol::response_writer > --> $1800c28f#fc
TRACE gdbstub::protocol::recv_packet > <-- $m8002bbac,4#1f
TRACE gdbstub::protocol::response_writer > --> $1800c28f#fc
TRACE gdbstub::protocol::recv_packet > <-- $vCont;s:p1.1;c:p1.-1#f7
ERROR gdbstub::stub::core_impl::resume > GDB client sent resume action not reported by vCont?
ERROR gdbdebugger::gdb_integration > gdbstub encountered a fatal error: Client sent an unexpected packet. Please re-run with log trace-level logging enabled and file an issue at https://github.com/daniel5151/gdbstub/issues

debuglog.txt

[daniel5151]

Huh, well, that's certainly interesting...

You're using MIPS, and yet GDB is sending a single-step packet, which doesn't line up with what other folks reported (when we were building out that support_single_step infra).

So, two theories here:

1. Different MIPS flavors have different behavior
2. You're using LLDB, which doesn't do the same thing as GDB

Lets start by testing that latter theory...

Are you using LLDB with `gdbstub, and if so, can you check what happens if you try and use GDB instead?

[lemmy-64]

I was using the gdb that came bundled with CLion, not lldb. So it's either 1. or 3.:
3. CLion's gdb behaves differently than upstream

I'm on Apple Silicon, so there is not good upstream gdb unfortunately.

[daniel5151]

@bet4it, IIRC you did the digging for MIPS's single step behavior, and mentioned that this shouldn't happen (since MIPS doesn't support hardware single stepping), hence why we introduced that extra Ignored variant.

...but it seems to be that this isn't strictly true?

Switching MIPS over to Required seems pretty unfortunate, as based on other folk's experiences, there are indeed MIPS targets that never use single step. Optional isn't right either, since it would result in this very same error in implementations that don't impl single step support (yet recv a single step packet anyways).

---

This is a tricky situation, since the whole point of this guard rail was to prevent folks from running into these opaque "packet unexpected" issues, but if the GDB client simply doesn't respect the vCont? response on MIPS... ¯\_(ツ)_/¯. Maybe its just unavoidable, and the best we can do is to reduce the scope of this guard rail to preventing the most basic issue on x86 platforms (where we know that single-step is effectively required by all targets) + improve the error message in this specific "unexpected packet" case pointing out this weird GDB bug.

[bet4it]

How can I reproduce it?

[daniel5151]

FYI: since this issue was open, #125 came in, which is also related to this guard-rail not doing what it's supposed to do.

In what is likely going to be an "I told you so" moment for ya bet4it, I think it might make sense to nix this guard rail entirely, and just invest in a better error message when GDB clients send step packets to targets that don't explicitly support stepping behavior.

To be clear: the fact that the GDB client often doesn't respect a target's response to vCont? when it comes to single-step support is clearly an upstream bug, and while it'd be great to shield gdbstub users this nonesense, I don't think this guard-rail approach has proven to be particularly tenable...

Indeed, past me might have over-engineered this thing quite a bit, and reflecting on this code again: I think a simple improvement to the error message (that mentions this upstream bug) would have been a sufficient mitigation on gdbstub's end.

Unless there are objections to that line of thought (i.e: you think this guard rail is salvageable), I'll likely go about deprecating this guard rail in 0.6.x, and then removing it in 0.7

[bet4it]

I found that if the target description XML is set to

<target version="1.0">
  <architecture>mips</architecture>
  <feature name="org.gnu.gdb.mips.cpu">
  </feature>
</target>

GDB will not send single-step packet.

But if the target description XML is set to

<target version="1.0">
  <architecture>mips</architecture>
  <feature name="org.gnu.gdb.mips.cpu">
    <reg name="r0" bitsize="64"/>
  </feature>
</target>

GDB will send single-step packet.

So the behavior of GDB depends on target description XML🙃

[daniel5151]

Ahh, GDB, you're so cool and consistent 🥲

Thanks for the nugget of insight bet4it - that's good to know, even if it kinda wants to make me cry.

But yeah, as I said in the comment above + over on #128 (comment), I suspect the best thing to do here is to simply throw in the towel on the SingleStepBehavior guard rail, and work to improve the error message when the GDB client sends a step packet when no single-step mode has been implemented.

[daniel5151]

Closing this now that SingleStepBehavior has been removed in release 0.7.0