gdb: `mips64` is an unknown architecture

[AlexApps99]

gdb: `mips64` is an unknown architecture

[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]

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

[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)