Skip to contentSkip to conversation

IP28: "Inconsistent ISA" messages during kernel build

DISCUSSION Joshua Kinard 4 participants 7 messages May 12, 2015 MIPS

lore
Share & tools
lore
#0 lore raw

Has anyone tried to build an IP28 kernel lately? I've been getting quite a few warnings out of the linker regarding e_flags and the new .MIPS.abiflags stuff.
Not seen it on the other SGI platforms, so I am assuming this has something to
do with what flags are passed to the compiler/linker.

mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA between e_flags and .MIPS.abiflags mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA extensions between e_flags and .MIPS.abiflags

Seeing this on a build of 4.0.2 based off of a 20150418 checkout from git.

--J

#1 lore raw
Quoted 6 lines · Joshua Kinard

Has anyone tried to build an IP28 kernel lately? I've been getting quite a few warnings out of the linker regarding e_flags and the new .MIPS.abiflags stuff.
Not seen it on the other SGI platforms, so I am assuming this has something to
do with what flags are passed to the compiler/linker.

Quoted 9 lines

mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA between e_flags and .MIPS.abiflags mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA extensions between e_flags and .MIPS.abiflags

Seeing this on a build of 4.0.2 based off of a 20150418 checkout from git.

--J

Hi,

I presume you are using binutils >= 2.25? I have seen this problem in my local build tests as well and I discussed this with Matthew (now on CC). It seems it's an 'innocent' warning added to binutils 2.25 but I am not sure if this is now fixed or not. Matthew might be able to provide more information.

Signature · 1 line
markos
#2 lore raw
Quoted 18 lines · Markos Chandras
Quoted 3 lines · Joshua Kinard

Has anyone tried to build an IP28 kernel lately? I've been getting quite a few warnings out of the linker regarding e_flags and the new

.MIPS.abiflags stuff.

Quoted 9 lines

Not seen it on the other SGI platforms, so I am assuming this has
something to do with what flags are passed to the compiler/linker.

mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA between e_flags and .MIPS.abiflags mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA extensions between e_flags and .MIPS.abiflags

Seeing this on a build of 4.0.2 based off of a 20150418 checkout from

git.

Quoted 3 lines

--J

Quoted 7 lines

Hi,

I presume you are using binutils >= 2.25? I have seen this problem in my local build tests as well and I discussed this with Matthew (now on CC). It seems it's an 'innocent' warning added to binutils 2.25 but I am not sure if this is now fixed or not. Matthew might be able to provide more information.

I don't really know what an IP28 kernel is. What is the -march for this? There is an issue with -march=xlp as the XLP is marked as an XLR in the e_flags which is a mips64 but the xlp is a mips64r2 which is correctly annotated as such in the .MIPS.abiflags. I haven't quite figured out what to do about this yet.

Thanks,
Matthew

#3 lore raw
Quoted 27 lines · Matthew Fortune
Quoted 18 lines · Markos Chandras
Quoted 3 lines · Joshua Kinard

Has anyone tried to build an IP28 kernel lately? I've been getting quite a few warnings out of the linker regarding e_flags and the new

.MIPS.abiflags stuff.

Quoted 9 lines

Not seen it on the other SGI platforms, so I am assuming this has
something to do with what flags are passed to the compiler/linker.

mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA between e_flags and .MIPS.abiflags mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA extensions between e_flags and .MIPS.abiflags

Seeing this on a build of 4.0.2 based off of a 20150418 checkout from

git.

Quoted 3 lines

--J

Quoted 7 lines

Hi,

I presume you are using binutils >= 2.25? I have seen this problem in my local build tests as well and I discussed this with Matthew (now on CC). It seems it's an 'innocent' warning added to binutils 2.25 but I am not sure if this is now fixed or not. Matthew might be able to provide more information.

Quoted 5 lines

I don't really know what an IP28 kernel is. What is the -march for this? There is an issue with -march=xlp as the XLP is marked as an XLR in the e_flags which is a mips64 but the xlp is a mips64r2 which is correctly annotated as such in the .MIPS.abiflags. I haven't quite figured out what to do about this yet.

It's one of the SGI platforms. Specifically, the Indigo2 Impact R10000. Here's a short list supported by Linux:

IP22: Indy, Indigo2 (R4x00)
IP27: Origin 200/2000, Onyx2 (R10K/R12K/R14K)
IP28: Indigo2 Impact R10000 (R10K)
IP30: Octane (R10K/R12K/R14K) (not in mainline)
IP32: O2 (R5000, RM5200, RM7000) (R10K/R12K not supported)

Valid -march values for these are:

IP22 (Indy): mips3, mips4, r4000, r4400, r4600, r5000 IP22 (Indigo2): mips3, r4000, r4400, r4600 IP27 to IP30: mips4, r10000, r12000, r14000
IP32: mips4, r5000, rm5200, rm7000

The IPxx number basically indicates the hardware platform. There's also a "software" IPxx number for some platforms to indicate minor variations of the hardware. E.g., hardware IP22 refers to both Indigo2 and Indy, but Indy is "software" IP24. An IP27 Origin 2000/Onyx2 with R12K/R14K node boards is "software" IP31. Origin 3x0/3000 is "software" IP35, Fuel is IP45, and Tezro is IP53, though collectively, all three have a hardware of IP35. Yes, SGI was weird.

The Indigo2 was the odd duck of the group. It has three hardware IPxx variants, and I guess the "software" IPxx is the same for each. The R4x00 CPU is IP22, the rare R8000 is IP26, and the R10000 is IP28. It's also a non-coherent machine, which means the R10000's speculative execution feature comes into play and you're lucky to keep an IP28 kernel running for more than a few hours if you actually use it for anything. IP32 (the O2) is also a non-coherent platform and supports the R10K/R12K CPUs, but little effort has been made to run Linux reliably on those.

As the GCC/MIPS maintainer, if you've ever wondered what the -mr10k-cache-barrier switch was used for, it's specifically for building kernels on IP28 (and maybe IP32) systems running the R10000 CPU. Check out the section in the R10000 manual on "Side effects of speculative execution" if you ever get bored and gasp in wonder at SGI's insanity...

Btw, for anyone interested, there's a good condition R8000 I2 on eBay, item #141663824264. Such an odd CPU, that R8000...

Signature · 10 lines
Joshua Kinard
Gentoo/MIPS
[email protected]
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
#4 lore raw
In reply to Matthew Fortune

Hi,

Quoted 7 lines · Matthew Fortune
Quoted 5 lines · Markos Chandras

I presume you are using binutils >= 2.25? I have seen this problem in my local build tests as well and I discussed this with Matthew (now on CC). It seems it's an 'innocent' warning added to binutils 2.25 but I am not sure if this is now fixed or not. Matthew might be able to provide more information.

Quoted 5 lines

I don't really know what an IP28 kernel is. What is the -march for this? There is an issue with -march=xlp as the XLP is marked as an XLR in the e_flags which is a mips64 but the xlp is a mips64r2 which is correctly annotated as such in the .MIPS.abiflags. I haven't quite figured out what to do about this yet.

Not sure if related, but I'm getting tons of these warnings as well already when compiling toolchain alone (GCC 5.1, binutils 2.25, GLIBC 2.20) for arch=octeon+ and soft-float. This will make e.g. GCC testsuite useless as pretty much everything fails with excess errors. Currently for OCTEON toolchain I need to downgrade to binutils 2.24. :-(

A.

#5 lore raw
Quoted 18 lines · Aaro Koskinen

Hi,

Quoted 3 lines · Matthew Fortune
Quoted 2 lines · Markos Chandras

I presume you are using binutils >= 2.25? I have seen this problem in my local build tests as well and I discussed this with Matthew

(now on CC).

Quoted 5 lines
Quoted 3 lines

It seems it's an 'innocent' warning added to binutils 2.25 but I am not sure if this is now fixed or not. Matthew might be able to provide more information.

I don't really know what an IP28 kernel is. What is the -march for

this?

Quoted 4 lines

There is an issue with -march=xlp as the XLP is marked as an XLR in the e_flags which is a mips64 but the xlp is a mips64r2 which is correctly annotated as such in the .MIPS.abiflags. I haven't quite figured out what to do about this yet.

Quoted 5 lines

Not sure if related, but I'm getting tons of these warnings as well already when compiling toolchain alone (GCC 5.1, binutils 2.25, GLIBC 2.20) for arch=octeon+ and soft-float. This will make e.g. GCC testsuite useless as pretty much everything fails with excess errors. Currently for OCTEON toolchain I need to downgrade to binutils 2.24. :-(

I think this will be related but for a different underlying reason. I'm afraid I didn't see the fact that we don't actually have link tests that hit every architecture and the few I chose to add explicitly were consistent. I've added a bug for binutils about this:

Bug 18401 - MIPS -march=xlp results in inconsistent ISA markers
https://sourceware.org/bugzilla/show_bug.cgi?id=18401

I'll try and take a look at a fix (and link test coverage for all archs).

Thanks,
Matthew

#6 lore raw
In reply to Markos Chandras
Quoted 16 lines · Markos Chandras
Quoted 6 lines · Joshua Kinard

Has anyone tried to build an IP28 kernel lately? I've been getting quite a few warnings out of the linker regarding e_flags and the new .MIPS.abiflags stuff.
Not seen it on the other SGI platforms, so I am assuming this has something to
do with what flags are passed to the compiler/linker.

Quoted 9 lines

mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA between e_flags and .MIPS.abiflags mips64-unknown-linux-gnu-ld: fs/ext4/symlink.o: warning: Inconsistent ISA extensions between e_flags and .MIPS.abiflags

Seeing this on a build of 4.0.2 based off of a 20150418 checkout from git.

--J

Quoted 7 lines

Hi,

I presume you are using binutils >= 2.25? I have seen this problem in my local build tests as well and I discussed this with Matthew (now on CC). It seems it's an 'innocent' warning added to binutils 2.25 but I am not sure if this is now fixed or not. Matthew might be able to provide more information.

Yup, binutils-2.25. My guess, going by Matthew's description of the XLR, may be related to one of the fields storing "mips4" as the -march, and the other field storing "r10000". I haven't looked at the ELF sections yet, though, to verify that. Since I am not seeing this on the other platforms (IP27, IP30, & IP32), I'm guessing it's possibly something in the arch/mips/Makefile then?

At least it's harmless, but it does clutter the screen up with a ton of warnings.

Signature · 10 lines
Joshua Kinard
Gentoo/MIPS
[email protected]
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic