nbdd0121
MIPS Support
A few notes about this PR (for when/if it's mergable):
- We should upstream Arch definitions to gimli (assuming they're interested)
- Similar to RISCV and I think the
FP1..=32registers are optional depending on configuration; need to figure out correcttarget_featuresto support them correctly - Depending on the configuration, I think there can be far more total registers, GP/FP support should be enough for things generally
Tenatively pushing a fix for that build error, need to test at home, but you're free to kick it off if you want :)
Well that's something, one segfault, and one reproduction of the unwind failure. The segfault is concerning. 😄
There we go, fixed those errors, I omitted $sp and $fp somewhere along the way which... would definitely explain a lot. My apologies, I was definitely getting tunnel vision when I made those changes last night.
Alright, ready for another test I think. Decided to restore some asm I removed just to keep it inline with the other arches. Still encountering the stack unwind failure, but I think the asm is shored up.
The restoration code still needs to restore volatiles, since personality function may choose to set them to certain values (although I think this rarely happens in practice). They can also be set by dwarf instructions.
That one triggered an illegal instruction fault? Maybe I should avoid touching $at, $k0, $k1 out right? Or unrelated you think? 🙂
Absolutely amazing work. I'm really sorry you ended up needing to do the heavy lifting yourself, but thanks a million. I know this is super niche, and likely was a bit frustrating considering the lengthy back and forth. 🙏
Unfortunately it seems panics are still failing on the PSP itself, but now I can be mostly certain it's an issue with lld itself or the combination of mips and fde-static. Would it make sense to add a test for non-libc targets? I suppose the tricky thing about that would be providing the __eh_frame symbol in a way that would work across the target matrix.
As for mips support itself, I'll take some time tomorrow evening and get this PR cleaned up (need to find the correct the fp32 target_feature + open a PR with gimli + add support for -fno-oddregs; which should all be straight forward enough)
P.S. it's not much, but I sent a sponsorship your way as thanks 🙂
I noticed that your gimli PR was merged and I updated the PR to use new gimli types. CI is happy now, but it does spit a lot warnings that single-float feature doesn't exist.
Hmm, yeah I recall having issues trying to pinpoint the clang cpu feature needed to gate double precision, and it might simply be a matter of cargo not supporting any of them at all. I can have a look again soon. 🙂