Add .cfi_{start,end}proc annotations for MIPS assembly

[arichardson]

Summary

This gives me sensible GDB backtraces when I set an breakpoint in an
assembly function such as suword64.
I also added _FRAME_{RETURN,STACK}_REG macros to asm.h since this makes it
easier for us to merge this to CheriBSD (we use $c11/$c17 instead of $sp/$ra
for CHERI pure-capability).

Obtained from: CheriBSD

Test Plan

compiles and boots

[arichardson]

Drop unnecessary change

[adrian]

Hm, how's this work on mips32? Has anyone spun this up in qemu on malta+mips32?

[arichardson]

In D27088#604697, @adrian wrote:

Hm, how's this work on mips32? Has anyone spun this up in qemu on malta+mips32?

I've not tried building MIPS32 but I don't see why it would be any different from MIPS64. It just tells the compiler to place some extra data in .eh_frame.

[arichardson]

In D27088#604702, @arichardson wrote:

In D27088#604697, @adrian wrote:

Hm, how's this work on mips32? Has anyone spun this up in qemu on malta+mips32?

I've not tried building MIPS32 but I don't see why it would be any different from MIPS64. It just tells the compiler to place some extra data in .eh_frame.

Although there might be some additional assembly files with extra .cfi annotations. Let me run a build.

[arichardson]

MALTA currently fails with

ld: error: /tmp/inckern-c4cc73.o:(.eh_frame): PC offset is too large: 0xfffffffeff7eae24

I guess I'll just not remove the .cfi annotations for that function. Although I don't quite understand why I'm getting that error.

[arichardson]

In D27088#604704, @arichardson wrote:

MALTA currently fails with

ld: error: /tmp/inckern-c4cc73.o:(.eh_frame): PC offset is too large: 0xfffffffeff7eae24

I guess I'll just not remove the .cfi annotations for that function. Although I don't quite understand why I'm getting that error.

Actually it seems like the PC-relative relications that clang generates are > 32-bits everywhere not just in that file. This sounds like a toolchain bug. Might have to disable it for MIPS32.

[adrian]

Hm, wanna see if it compiles using gcc-6 instead? mips32 SHOULD compile now, as long as you disable ZFS.

(I'm still working on the GCC build fixes.)

Or if you want until the weekend, I can test this out in my local mips32 + gcc6 setup for you.

Did you want to poke this upstream to llvm and find out what we're doing wrong or if it's a toolchain bug?

[arichardson]

In D27088#604714, @adrian wrote:

Hm, wanna see if it compiles using gcc-6 instead? mips32 SHOULD compile now, as long as you disable ZFS.

(I'm still working on the GCC build fixes.)

Or if you want until the weekend, I can test this out in my local mips32 + gcc6 setup for you.

Did you want to poke this upstream to llvm and find out what we're doing wrong or if it's a toolchain bug?

It works fine with GCC+bfd since ld.bfd does some rewriting of .eh_frame.

[arichardson]

This may help clang: https://reviews.llvm.org/D80392

[emaste]

this could be abandoned now, MIPS support has been retired