[LLVMdev] [3.7.0] Two late issues with cross compilation to mips (original) (raw)

Simon Atanasyan simon at atanasyan.com
Wed Jul 29 05:03:59 PDT 2015


Hi Daniel,

I am on a vacation now till the Aug 3 but I can take a look at these problems. What is the most important?

As to the issue #3 - do we need to keep compatibility with the old mips-mti-linux-gnu toolchain layout?

Simon

On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:

The issues are:

1. Almabench has some significant numerical differences and fails the reference check for some configs. I'm investigating this one at the moment but early indications are that it's a similar (but different) problem to the one we had in LLVM 3.6.2. 2. Read-only exception tables have broken compatibility with the ~2 year old gcc toolchains I was using for release testing cross compilation. This isn't a problem for most test-suite runs since we can just update the assembler but is causing trouble for microMIPS. More recent toolchains lack the microMIPS multilib I was using and migrating to the new one is causing link failures. These failures are related to ELF header bits specifying the SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the –mnan=2008 isn't reaching the assembler. 3. Clang is incompatible with changes to the mips-mti-linux-gnu sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are still multilib'd (albeit with a reduced set) but some of the include paths aren't anymore. It's also no longer correct to include sysroot/include (this path is added by common code) since this skips some function definitions. Instead, we must only include sysroot/usr/include like GCC does. There may be more details but so far the fix doesn't look simple. As far as I can tell, clang's multilib expects includes and libraries to have the same layout (osSuffix() seems to control both). The good news is that it's not a regression since we can use toolchains from before this layout change.



More information about the llvm-dev mailing list