[J-core] Linux SH build issues with 4.14

Rich Felker dalias at libc.org
Sat Dec 2 21:34:13 EST 2017

On Sat, Dec 02, 2017 at 06:48:59PM -0500, Rich Felker wrote:
> On Sun, Dec 03, 2017 at 12:25:10AM +0100, John Paul Adrian Glaubitz wrote:
> > On 12/02/2017 09:49 PM, John Paul Adrian Glaubitz wrote:
> > > On 12/02/2017 09:23 PM, John Paul Adrian Glaubitz wrote:
> > >> Compiler is gcc-7.
> > >>
> > >> I'll try a cross-compile with gcc-7 myself.
> > > 
> > > I can reproduce it with gcc-7 as a cross-compiler and the attached
> > > configuration which is derived from Debian's kernel configuration:
> > 
> > Switching to gcc-6 seems to avoid this issue and the kernel builds fine.
> OK, I don't have gcc 7. But since this works with gcc 6, it's almost
> surely a gcc bug. I can try to get a gcc 7 build for sh4 and test
> myself, but if you could send me a dump of gcc -S (or objdump -dr for
> the produced .o file, not quite as good but should be easier to make
> and should suffice) I can probably tell you right away what the
> reference to abort seems to have been generated from.

This is reproducible with a trivial test case:

int main(int argc, char **argv) { return argc/0; }

or what gcc7 optimizes it to:

int main(int argc, char **argv) { __builtin_trap(); }

The only change seems to be this new optimization; AFAICT gcc's sh
backend has always lacked a "trap" implementation, causing gcc to use
the (awful) default call to abort() to implement it.

I think this should be filed as a bug with gcc. The right fix is
probably adding an implementation for trap using a
permanently-undefined opcode. IIRC that's fffe or feff or similar but
I'd have to check the official ISA manual again to make sure.

Adding gcc target maintainers on CC.


More information about the J-core mailing list