[llvm-dev] [libunwind][Mips] Problem using gas to assemble UnwindRegistersSave.S

[Richard Pennington via llvm-dev]

The latest TOT of libunwind fails for me when I build
UnwindRegistersSave.S for the Mips. My copy of clang uses a 2.25
binutils Mips assembler.
This is the message I get:

"/home/rich/ellcc/bin/mips-elf-as" -o
/tmp/UnwindRegistersSave-a2c974.o -EL /tmp/UnwindRegistersSave-545450.s
src/UnwindRegistersSave.S: Assembler messages:
src/UnwindRegistersSave.S:99: Error: opcode not supported on this
processor: mips1 (mips1) `teq $0,$0'

If I compile with -integrated-as it assembles as expected.

I was able to get it to work without the integrated assembler with this
change:

#
# extern int unw_getcontext(unw_context_t* thread_state)
#
# Just trap for the time being.
DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
.set mips32r2
teq $0, $0

#elif defined(__ppc__)

telling the assembler to allow r2 instructions.

Should the integrated assembler be enabled by default for the Mips? It
looks as if the stock clang does not use the integrated assembler yet.

-Rich
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Vasileios Kalintiris via llvm-dev]

Hi Richard,

Clang doesn't have support for MIPS I. The trap-on-condition instructions were added in MIPS II and they should work fine. This is why it works with ".set mips32r2".

Which version of the ISA did you specify when you used the integrated assembler?

Thanks,
Vasileios

[Richard Pennington via llvm-dev]

On 09/27/2015 06:41 PM, Vasileios Kalintiris wrote:
> Hi Richard,
>
> Clang doesn't have support for MIPS I. The trap-on-condition instructions were added in MIPS II and they should work fine. This is why it works with ".set mips32r2".
>
> Which version of the ISA did you specify when you used the integrated assembler?
>
> Thanks,
> Vasileios
>
>

Hi Vasileios,

The integrated assembler works great. It was gas that complained.
Apparently gas must default to MIPS I

-Rich

[Daniel Sanders via llvm-dev]

> The integrated assembler works great. It was gas that complained.
> Apparently gas must default to MIPS I

That depends on the exact toolchain you have since the default is often overridden but the default-default is MIPS-I. Clang defaults to MIPS32R2/MIPS64R2 depending on the triple at the moment.

> Should the integrated assembler be enabled by default for the Mips?

Not yet. There's a number of quiet mis-assembly bugs at the moment. The plan is to switch it on once it's good enough for the Linux kernel and see what bug reports come back.

[Daniel Sanders via llvm-dev]

> > Should the integrated assembler be enabled by default for the Mips?
>
> Not yet. There's a number of quiet mis-assembly bugs at the moment. The
> plan is to switch it on once it's good enough for the Linux kernel and see what
> bug reports come back.

Having said this, we had our first successful boot of the Linux kernel build with clang and -fintegrated-as today.

[Richard Pennington via llvm-dev]

On 09/30/2015 05:48 AM, Daniel Sanders wrote:
>>> Should the integrated assembler be enabled by default for the Mips?
>> Not yet. There's a number of quiet mis-assembly bugs at the moment. The
>> plan is to switch it on once it's good enough for the Linux kernel and see what
>> bug reports come back.
> Having said this, we had our first successful boot of the Linux kernel build with clang and -fintegrated-as today.
>

Very cool!

-Rich

[Richard Pennington via llvm-dev]

On 09/30/2015 05:48 AM, Daniel Sanders wrote:

>>> Should the integrated assembler be enabled by default for the Mips?
>> Not yet. There's a number of quiet mis-assembly bugs at the moment. The
>> plan is to switch it on once it's good enough for the Linux kernel and see what
>> bug reports come back.
> Having said this, we had our first successful boot of the Linux kernel build with clang and -fintegrated-as today.
>

Today just for fun I built clang/LLVM, libc++, libc++abi, libunwind,
musl, binutils, and GDB for Mips
using the integrated assembler. It seemed to work flawlessly.
Now I'm trying to use the newly built tools to build themselves again.
So far so good, but it will take
a while because I have to run the tools using QEMU Linux user space
emulation.

-Rich

[Vasileios Kalintiris via llvm-dev]

Hi Rich,

> Today just for fun I built clang/LLVM, libc++, libc++abi, libunwind,
> musl, binutils, and GDB for Mips using the integrated assembler

I've tried something similar but I used LLD, LLDB and the builtins library
from compiler-rt. Static builds were running fine but there are still
some small issues with shared linking which I'm trying to resolve.

I just want to clarify that libunwind isn't really supported on MIPS at the
moment. Here's the message from the commit (r248673) that enabled the building
of libunwind for MIPS:

Currently, libunwind doesn't support MIPS. However, with this patch
we do allow the library to build, and we warn the user about the lack of
support for MIPS. Also, the dummy unw_getcontext() implementation for MIPS just
traps on function entry in order to avoid any confusion with silent/weird
failures at runtime.

This allows us to test an LLVM-based toolchain without the dependency on a
GCC toolchain. Of course, C++ exception handling and other things that depend
on stack unwinding will not work until we add a proper implementation of the
stub functions.

- Vasileios

[Richard Pennington via llvm-dev]

Hi Vasileios,

On 10/01/2015 04:07 AM, Vasileios Kalintiris wrote:
> I've tried something similar but I used LLD, LLDB and the builtins library
> from compiler-rt. Static builds were running fine but there are still
> some small issues with shared linking which I'm trying to resolve.
>
> I just want to clarify that libunwind isn't really supported on MIPS at the
> moment. Here's the message from the commit (r248673) that enabled the building
> of libunwind for MIPS:
>
> Currently, libunwind doesn't support MIPS. However, with this patch
> we do allow the library to build, and we warn the user about the lack of
> support for MIPS. Also, the dummy unw_getcontext() implementation for MIPS just
> traps on function entry in order to avoid any confusion with silent/weird
> failures at runtime.
>
> This allows us to test an LLVM-based toolchain without the dependency on a
> GCC toolchain. Of course, C++ exception handling and other things that depend
> on stack unwinding will not work until we add a proper implementation of the
> stub functions.
>

I also built compiler-rt. I do understand libunwind isn't ready for the
MIPS, but it is good enough for clan/LLVM, etc.
My build of everything using the integrated assembler built tools worked
perfectly.

-Rich