Thanks for sending in this bug report!
Lets dig in here and see what's going on...

Assuming I found the right repo - this is the gdbstub integration in your kernel, yes? https://github.com/uglyoldbob/doors-os/blob/master/kernel/src/gdbstub.rs

A few initial observations:

• GDB is clearly not thrilled about the extra 24 bytes of "unknown" registers (denoted by xx) in the packet response
• Since you're using the built-in x86_64 arch from gdbstub_arch, this part of the response corresponds to the following lines of source code: https://github.com/daniel5151/gdbstub/blame/e2329b80c2d51ee0ab4678365a35b27b51f32235/gdbstub_arch/src/x86/reg/core64.rs#L75-L78.
  • This code was added 5 years ago, and from a cursory search of github, has seems to have been used successfully in many other gdbstub integrations

This is most perplexing indeed...

As a next step, could you confirm I'm understanding the situation right, and also, try this one thing for me?

Can you try removing the explicit set architecture directive from your GDB init script, and seeing what happens if you let GDB infer the target type based on the target.xml response?

Yes that is the correct repo. I'm currently working out of the packetrx branch, which is slightly different on the gdbstub (but probably not enough to matter yet).

I tried removing the set architecture line from the script. It did not change the results.

(gdb) show arch
The target architecture is set to "auto" (currently "i386:x86-64").

I tried removing the extra 24 bytes in core64.rs in gdbstub_arch and it seems to fix the problem. Probably not the best solution. Maybe it is a deviation specific to the mingw version of gdb?

That's very interesting indeed...

While it would certainly be good to get to the bottom of why your particular GDB client version isn't playing nice with the existing arch implementation, I'm not particularly inclined to change the current implementation in gdbstub_arch just yet. After all, it appears to have been working fine for many years now, and I worry that fixing your issue might accidentally break other folks.

If you'd like to help me debug here, I would certainly appreciate it if you could try connecting to your kernel using an alternative GDB client. e.g: you could install gdb inside WSL2, and see if you're still seeing the same behavior. e.g: see what happens if you connect via lldb.

In the meantime though, my actionable advice for you would be to "fork" a copy of the gdbstub_arch X86_64 Arch implementation into your own project, and tweak it to omit those problematic padding bytes. While this is technically a workaround, it's important to note that simply having a project-local Arch shouldn't be considered to be a "bad thing". Many projects that use gdbstub opt to forgo using gdbstub_arch if they need something tailor-suited to their particular scenario.

If you don't mind - I'll just go ahead and keep this issue open, renaming it to something a bit more generic, in case other folks run into this same issue.

I don't mind at all. I'll see about doing some of the debugging with other gdb.

In wsl2, ubuntu gdb works both with and without the 24 bytes at the end.

Very interesting indeed.

What GDB version were you running inside WSL2?

Gdb version in wsl2 is GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git

It would be good to narrow down if the issue is related to the GDB version, or the mingw version of GDB.

If you have a chance, it'd be great to smoke-test some other versions of GDB (both via mingw, and in wsl2), and see what the behavior matrix looks like.

I'm facing a similar issue when trying to debug a 32-bit Windows executable, my GDB client doesn't like the 4 bytes of "padding" here:

I think I figured out where this "padding" comes from. For 32-bit x86, it's this Linux-only orig_eax register: https://github.com/bminor/binutils-gdb/blob/f92db640ca2ff6fd12997974b441b81894d9cfa4/gdb/features/i386/32bit-linux.c

And for x86-64, the 24 extra bytes are orig_eax, as well as fs_base and gs_base: https://github.com/bminor/binutils-gdb/blob/f92db640ca2ff6fd12997974b441b81894d9cfa4/gdb/features/i386/64bit-segments.c#L12 (Maybe relevant to #52, turns out these registers were here all along.)

So, the x86 implementation in gdbstub_arch is specifically for Linux targets instead of being a generic x86 architecture. But, GDB seems fine if the register packet is too short, it will just assume the missing registers aren't available (https://github.com/bminor/binutils-gdb/blob/f92db640ca2ff6fd12997974b441b81894d9cfa4/gdb/remote.c#L8999). So maybe we can just remove the padding and call it a day?

Excellent sleuthing!

Given that this extra padding data is not user-controllable, it seems reasonable to publish a new minor revision of gdbstub_arch that omits this extra padding, and see if that fixes the issue for folks.

@jamcleod, as the original implementer of i386 support (via #23), do you have any thoughts / concerns about that?

In the meantime though, @cadmic, feel free to send in a PR tweaking this behavior. I don't mind shipping a new gdbstub_arch revision with this "bug fix", and if it turns out that the bug fix itself causes a regression (e.g: it turns out some clients aren't able to gracefully handle the undersized packet), we can yank the new revision, and come back to the drawing board to think of a different strategy here.

Of course, the meta-issue here is that until we have a reasonable approach towards #12, gdbstub_arch will be forced to go along one of two routes: shipping Arch implementations that target the "base subset" of registers available across a particular architecture's "family", or, having a fractal number of different x86::{linux, windows, etc...} Arch impls to account for all the different variants. Of these two routes, the former seems easier... but having some plan for supporting the latter in a sustainable, long-term way would be great.