Closed AlexApps99 closed 2 years ago
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.
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)
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?
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.
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?
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
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.
Also pinging @starfleetcadet75, in case he has any insights here (he's the one who upstreamed these arch impls back in the day)
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
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.
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.
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
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 arch
es 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.
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
.
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)
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)
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):
Connecting through GDB, setting
arch
(also causes errors):Connecting through GDB, setting
arch
andmips abi
Example for comparison (note I don't need to set anything to connect):
It seems there is no such architecture as
mips64
. Here are all the valid architectures that can be set in GDB: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