[LLVMdev] Pre-built big-endian MIPS32r2 binaries

Daniel Sanders Daniel.Sanders at imgtec.com
Wed Jul 30 03:05:35 PDT 2014


Just to update this thread. These binaries have been uploaded and are now available from http://llvm.org/pre-releases/3.5/.

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Daniel Sanders
Sent: 28 July 2014 09:41
To: Bill Wendling (isanbard at gmail.com)
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: Re: [LLVMdev] Pre-built big-endian MIPS32r2 binaries

I don't have access to the llvm.org SFTP at the moment. Anton K is sorting this out for me but in the meantime could someone upload https://www.dropbox.com/s/23ff0z8ltc7rybk/clang%2Bllvm-3.5-rc1-mips-unknown-linux-gnu.tar.xz for me?

Thanks

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Daniel Sanders
Sent: 25 July 2014 12:09
To: Bill Wendling (isanbard at gmail.com)
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: [LLVMdev] Pre-built big-endian MIPS32r2 binaries

Hi,

I'm pleased to say that my latest attempt at running test-release.sh finished with minor issues (see below) so I'm planning to provide an big-endian MIPS32r2 pre-built binary in the LLVM 3.5 as an experimental/beta release. I was originally hoping to provide little-endian binaries too but I think there's insufficient time remaining for me to get that ready in time for Phase 1 testing.

The minor issues are that 'make check-all' fails tools/clang/test/Driver/cl-x86-flags.c since it assumes the default target was X86. I believe this is already fixed on the trunk. The other is that two objects are different between phase 2 and 3 (ToolChains.o and llvm-config.o).

There are a couple important requirements for these binaries beyond a Big-endian MIPS32r2. A recent Linux kernel will be required to avoid hitting a gap in the kernel's floating point emulation (mthc1 and mfhc1 were not emulated). I'm currently using a patched 3.4.27 kernel on my test system to resolve this but I'm told that the relevant bugfix is in Linux 3.14. A recent binutils will also be required. My test system currently has a top-of-tree binutils but 2.24 is expected to work (and I intend to test this).

I needed two patches to test-release.sh to make it work, the first was simply to retrieve the cfe project from the branch instead of the tag. This will be unnecessary for rc2 since the rc2 tag will contain the bugfix that I needed. The second was to add '-build=mips-unknown-linux-gnu' to the configure commands. This is to work config.guess picking mips64-unknown-linux-gnu which causes some issues due to known bugs in our handling of mips64*-* triples.

For reference, I'm currently testing on a fresh Big Endian MIPS32r2 Gentoo system. I intend to try Debian today but we will still require MIPS32r2 there since we lack MIPS-II code generation support. Here's the build command I used:
LANG=C CFLAGS=-mips32r2 CXXFLAGS=-mips32r2 ./test-release.sh -release 3.5 -rc 1 -triple mips-unknown-linux-gnu -no-64bit
Am I right in thinking that others use '-test-debug' and '-test-asserts' too?

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<http://www.imgtec.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140730/384bd798/attachment.html>


More information about the llvm-dev mailing list