gdb: mips64 is an unknown architecture

[AlexApps99]

Thanks to this amazing library, I've been able to set up debugging for my emulator.
There are a few errors that seem out of place (and don't happen on the ARM example provided) that have to do with gdbstub_arch's MIPS64 XML.

Connecting through GDB normally (causes errors):

(gdb) target remote localhost:6464
Remote debugging using localhost:6464
warning: while parsing target description (at line 1): Target description specified unknown architecture "mips64"
warning: Could not load XML target description; ignoring
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
Remote 'g' packet reply is too long (expected 312 bytes, got 576 bytes): 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000a4ffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000003f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f01f00a4ffffffff0000000000000000000000000000000004004070000000000000000000000000000000000000000000000000000000000000000000000000400000a400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000

Connecting through GDB, setting arch (also causes errors):

(gdb) set arch mips
The target architecture is set to "mips".
(gdb) target remote localhost:6464
Remote debugging using localhost:6464
warning: while parsing target description (at line 1): Target description specified unknown architecture "mips64"
warning: Could not load XML target description; ignoring
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
warning: while parsing target description (at line 1): Target description specified unknown architecture "mips64"
warning: Could not load XML target description; ignoring
Remote 'g' packet reply is too long (expected 360 bytes, got 576 bytes): 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000a4ffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000003f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f01f00a4ffffffff0000000000000000000000000000000004004070000000000000000000000000000000000000000000000000000000000000000000000000400000a400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000

Connecting through GDB, setting arch and mips abi

(gdb) set arch mips
The target architecture is set to "mips".
(gdb) set mips abi n64
(gdb) target remote localhost:6464
Remote debugging using localhost:6464
warning: while parsing target description (at line 1): Target description specified unknown architecture "mips64"
warning: Could not load XML target description; ignoring
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
warning: while parsing target description (at line 1): Target description specified unknown architecture "mips64"
warning: Could not load XML target description; ignoring
...

Example for comparison (note I don't need to set anything to connect):

(gdb) target remote 127.0.0.1:9001
Remote debugging using 127.0.0.1:9001
Reading /test.elf from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /test.elf from remote target...
Reading symbols from target:/test.elf...
main () at test.c:1
1	int main() {
...

It seems there is no such architecture as mips64.
Here are all the valid architectures that can be set in GDB:

(gdb) set arch mips<TAB>
mips                 mips:4300            mips:gs464           mips:loongson_2e
mips:10000           mips:4400            mips:gs464e          mips:loongson_2f
mips:12000           mips:4600            mips:interaptiv-mr2  mips:micromips
mips:14000           mips:4650            mips:isa32           mips:mips5
mips:16              mips:5000            mips:isa32r2         mips:octeon
mips:16000           mips:5400            mips:isa32r3         mips:octeon+
mips:3000            mips:5500            mips:isa32r5         mips:octeon2
mips:3900            mips:5900            mips:isa32r6         mips:octeon3
mips:4000            mips:6000            mips:isa64           mips:sb1
mips:4010            mips:7000            mips:isa64r2         mips:xlr
mips:4100            mips:8000            mips:isa64r3
mips:4111            mips:9000            mips:isa64r5
mips:4120            mips:gs264e          mips:isa64r6

As for how to make it recognized as 64 bit, I don't really know. The docs seem to suggest you'd need to set the width inside org.gnu.gdb.mips.{cpu,cp1,fpu,dsp}

Some links that might help making a proper XML:
https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html
https://sourceware.org/gdb/onlinedocs/gdb/MIPS-Features.html#MIPS-Features

[daniel5151]

You may be using a GDB client that wasn't built with support for the particular MIPS platform you're interested in. Try installing gdb-multiarch and seeing if that helps.

Unfortunately, I can't offer much help aside from that, as the architecture implementations under gdbstub_arch are community contributions. FWIW, the MIPS implementation in gdbstub_arch has been used successfully by several other users in the >2y since it was upstreamed...

And as a reminder: it's totally reasonable to forgo the implementations under gdbstub_arch, and manually provide a implementation of the Arch trait tailored to your particular emulator.

[AlexApps99]

I built gdb-multiarch from source yesterday, it's possible my sources were out of date (AUR), I'll check later.

I understand this is a community thing, I will probably make a PR later if nobody else fixes it.

The MIPS implementation does work, I have been using it, it's just that you need to specify some stuff before connecting. Doesn't need to be fixed urgently, assuming the issue isnt with my version of GDB (will check the version later today)

[daniel5151]

Sure, let me know what you find :)

One thing to note is that the target.xml data in the gdbstub_arch aren't fully-formed target definitions, and instead act as "hints" to the GDB client to fetch the full target.xml definitions for the specified architecture from its internal database of XML files.

This is different from something like, say, QEMU, which actually sends over a complete full-formed target.xml file back to the GDB client, which contains all the register defns in explicit detail.

Now that I type this out, I realize that I never actually documented this property of the target_xml IDET anywhere. I really should fix that...

---

On that note, what are you connecting to in that target remote 127.0.0.1:9001 example you provided?

[AlexApps99]

what are you connecting to

I should have specified, it's the singlethread arm emulator example in this repo.

It's worth noting, the AUR I built from was updated in 2022, and the mips64 arch was put in around 2 years ago.
So it's very likely that the mips64 arch doesn't exist on GDB anymore. The version I was using was reasonably recent.

[daniel5151]

Hmmm, interesting... @bet4it, you wouldn't have happened to work with mips64 recently, would you?

In any case, see if you can figure out what XML incantations are required to have the GDB client properly detect the architecture. An easy way to play around with this without having to fork gdbstub_arch is by using the TargetXmlOverride IDET.

If you figure it out, I'd be happy to upstream it.

EDIT: maybe the trick is to also include that <osabi> tag?

[AlexApps99]

I have GDB-multiarch 11.2, which AFAIK is latest.
List of valid osabi:

set osabi <TAB>
AIX           Darwin        LynxOS178     OpenVMS       SVR4          auto
Cygwin        FreeBSD       NetBSD        PikeOS        Solaris       default
DICOS         GNU/Hurd      Newlib        QNX-Neutrino  Windows       none
DJGPP         GNU/Linux     OpenBSD       SDE           WindowsCE

So I don't think that'll work

[AlexApps99]

Overriding to <target version="1.0"><architecture>mips</architecture></target> removed the need for set arch mips, but set mips abi n64 is still needed.
I'll try figure out how to get that in the XML.

[daniel5151]

Also pinging @starfleetcadet75, in case he has any insights here (he's the one who upstreamed these arch impls back in the day)

[AlexApps99]

Did a quick search on GitHub, I think the only way to make it 64-bit is changing the registers as I mentioned earlier:
https://github.com/Dillonb/n64/blob/74a4c20d8be11cb8fddd68175476ce2c923321d7/src/debugger/debugger.c#L8-L93
https://github.com/search?p=2&q=%22%3Carchitecture%3Emips%3C%2Farchitecture%3E%22&type=Code
https://github.com/rantoniello/valgrind/tree/21be3371beb74cff971e0bbf48fbecc7bf970e49/coregrind/m_gdbserver

They all seem to include definitions for all the registers

[daniel5151]

This seems like an unfortunate oversight on GDB's part. If you're feeling particularly altruistic, consider filing a bug report upstream on the GDB bugzilla :)

In any case, for our purposes, I think it'd be totally reasonable to update the gdbstub_arch implementation to explicitly send out the entire target.xml of the target platform. I'd be happy to merge any fixup PR sent my way!

---

FWIW, I think it actually makes sense to update all existing gdbstub_arch implementations to send fully-formed target.xml files (rather than relying on GDB's built-in defns). Not that I'm suggesting you do that or anything - I'm kinda just thinking out loud here... I'll probably spin up a tracking issue to tackle that work at some point.

[bet4it]

Hmmm, interesting... @bet4it, you wouldn't have happened to work with mips64 recently, would you?

Oh, I only test mips but not mips64😅

FWIW, I think it actually makes sense to update all existing gdbstub_arch implementations to send fully-formed target.xml files (rather than relying on GDB's built-in defns).

I think it's not necessary. People can override it if they want! We just provide a sample.

---

I think the best way to solve this problem: find a Linux machine than run on MIPS64 (either hardware or emulated by QEMU), start a gdbserver and connect from remote, capture the packets between them and use show architecture command to find what the architecture is set.

[AlexApps99]

I'd imagine the list I got from tab-completing on gdb-multiarch would be comprehensive.
Of those, none jump out as 64-bit registers/pointers (other than the 64-bit ISA ones), and that makes sense.
After all, these CPUs can operate in either 32 or 64 bit registers, either 32 or 64 bit addressing, and even either endian. This is on a single CPU.

That's probably why it's not exposed very well, and is done via GDB commands (set mips abi) rather than having its own arch

[AlexApps99]

Looking deeper, I found this:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/cpu-mips.c;hb=HEAD
It seems to contain a list of all MIPS arches supported.

Edit:
(From a comment in the source file above)

The default architecture is mips:3000, but with a machine number of zero.

mips:3000 is defined as 32 bit word and 32 bit address in the source file above.

When I modified the target XML to mips:4300 (my emulated CPU, which is defined as 64 bit word and address) it works.
Very surprising.

So I guess that's (kind of) a fix. Only problem is that we'd have to specify each particular CPU in the XML for each usecase, otherwise library users would be confused and it might lead to unexpected GDB side-effects.

[daniel5151]

Indeed, the current Arch trait's support for specifying target.xml files is quite inflexible, which is tracked under #12.

As per the linked issue, I only recently discovered the <xi:include> functionality that the GDB client supports, and now that I know it exists, I have a few ideas of how we can leverage it to support lightweight, yet fine-grained control over Arch features. I suspect that tackling this problem will be one of my main action items whenever I decide to put some more time into gdbstub...

---

As for the fix at hand - I have a sneaking suspicion that mips64 has always been busted, and that we ought to mark it for removal for now (via #[deprecated]). Alongside that deprecation, we should also add a doc-comment note to the mips submodule in gdbstub_arch that explains this current situation. Oh, and of course, we can also upstream a specific impl for mips:4300.

[AlexApps99]

I don't know if a specific impl for 4300 is a good idea, because that would open the floodgates for all the MIPS variants (most of which have the same register names, etc)

[daniel5151]

Yep, I'm well aware of that. That's just the reality of how the current Arch trait is modeled. It's not great, but it's what we've got ¯\_(ツ)_/¯. I wouldn't worry too much about "opening the flood gates" here.

You'll find that the same issue already exists in the context of ARM. Currently, there is a single implementation for ARMv4T (which is just aarch32), which means that someone wanting to support, say, ARMv5, would need a whole separate Arch implementation.

---

Even if you don't end up upstreaming this new arch, I'm glad you pointed out that mips64 is busted, since that's a bug and should be removed.

Let me know if you'd like to push up a PR that deprecates mips64 and/or upstreams your new MIPS impl. If you don't have the time, no problem - I'll leave this issue open and get around to fixing this myself at some point (hopefully soon)