linuxsh-dev

GCC-4 problems

[Manuel L. <ma...@ro...>]

Hello,

When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
linking fails with this error:

  LD      .tmp_vmlinux1
kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2

I tracked it to kernel/rtmutex.c, line 88:

#define rt_mutex_cmpxchg(l,c,n)	(cmpxchg(&l->owner, c, n) == c)

Apparently the "size" input value passed to cmpxchg is 
neither 4, 2 or 1 (tried a few others too but not sizeof(struct task_struct)).
Probably a compiler bug? (gcc-4.1.2, Gentoo)

Also, these exports need to be removed from sh_ksyms.c, they give
"undefined reference" errors:
__sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i

Kernel boots ok otherwise.

Thanks,

-- 
 Manuel Lauss

Re: GCC-4 problems

[Paul M. <le...@li...>]

On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
> linking fails with this error:
> 
>   LD      .tmp_vmlinux1
> kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [_all] Error 2
> 
> I tracked it to kernel/rtmutex.c, line 88:
> 
> #define rt_mutex_cmpxchg(l,c,n)	(cmpxchg(&l->owner, c, n) == c)
> 
> Apparently the "size" input value passed to cmpxchg is 
> neither 4, 2 or 1 (tried a few others too but not sizeof(struct task_struct)).
> Probably a compiler bug? (gcc-4.1.2, Gentoo)
> 
Have you tried 8? This was a problem before in another path..

Is CC_OPTIMIZE_FOR_SIZE the only thing you've set? You can try and avoid
the __HAVE_ARCH_CMPXCHG in the gcc4 case if you want to fix it up, but I
haven't hit this directly yet, so I'm hesitant to pull it in general for
something that looks like a single compiler issue.

You may also want to check with gcc-4.2.x.

> Also, these exports need to be removed from sh_ksyms.c, they give
> "undefined reference" errors:
> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> 
Interesting. We'll kill those then. I'd also like to be rid of
__udivdi3_* while we're at it, can you verify whether that causes you
problems or not?

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Hi Paul,

On Mon, Mar 19, 2007 at 05:33:30PM +0900, Paul Mundt wrote:
> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> > When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
> > linking fails with this error:
> > 
> >   LD      .tmp_vmlinux1
> > kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
> > make[1]: *** [.tmp_vmlinux1] Error 1
> > make: *** [_all] Error 2
> > 
> > I tracked it to kernel/rtmutex.c, line 88:
> > 
> > #define rt_mutex_cmpxchg(l,c,n)	(cmpxchg(&l->owner, c, n) == c)
> > 
> > Apparently the "size" input value passed to cmpxchg is 
> > neither 4, 2 or 1 (tried a few others too but not sizeof(struct task_struct)).
> > Probably a compiler bug? (gcc-4.1.2, Gentoo)
> > 
> Have you tried 8? This was a problem before in another path..

no change. I'll see if I can find out the exact number somehow...
 
> Is CC_OPTIMIZE_FOR_SIZE the only thing you've set? You can try and avoid
> the __HAVE_ARCH_CMPXCHG in the gcc4 case if you want to fix it up, but I
> haven't hit this directly yet, so I'm hesitant to pull it in general for
> something that looks like a single compiler issue.

Yes; no funky debug options. Simply removing CC_OPTIMIZE_FOR_SIZE creates
a booting kernel.

> > Also, these exports need to be removed from sh_ksyms.c, they give
> > "undefined reference" errors:
> > __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> > 
> Interesting. We'll kill those then. I'd also like to be rid of
> __udivdi3_* while we're at it, can you verify whether that causes you
> problems or not?

I removed all from __udivsi3 to __movstrSI16, no problems with GCC3 and 4.

Thanks,

-- 
 Manuel Lauss

Re: GCC-4 problems

[Paul M. <le...@li...>]

On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> Hello,
> 
> When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
> linking fails with this error:
> 
>   LD      .tmp_vmlinux1
> kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [_all] Error 2
> 
This fixed it for me, can you verify?

diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
index b1e42e7..4a6a19f 100644
--- a/include/asm-sh/system.h
+++ b/include/asm-sh/system.h
@@ -7,6 +7,7 @@
  */
 
 #include <linux/irqflags.h>
+#include <linux/compiler.h>
 #include <asm/types.h>
 
 /*

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

On Wed, Mar 28, 2007 at 03:45:07PM +0900, Paul Mundt wrote:
> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> > Hello,
> > 
> > When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
> > linking fails with this error:
> > 
> >   LD      .tmp_vmlinux1
> > kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
> > make[1]: *** [.tmp_vmlinux1] Error 1
> > make: *** [_all] Error 2
> > 
> This fixed it for me, can you verify?
> 
> diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
> index b1e42e7..4a6a19f 100644
> --- a/include/asm-sh/system.h
> +++ b/include/asm-sh/system.h
> @@ -7,6 +7,7 @@
>   */
>  
>  #include <linux/irqflags.h>
> +#include <linux/compiler.h>
>  #include <asm/types.h>
>  
>  /*


Yes it is fixed, thank you!

-- 
 ml.

Re: GCC-4 problems

[Paul M. <le...@li...>]

On Wed, Mar 28, 2007 at 09:28:17AM +0200, Manuel Lauss wrote:
> On Wed, Mar 28, 2007 at 03:45:07PM +0900, Paul Mundt wrote:
> > diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
> > index b1e42e7..4a6a19f 100644
> > --- a/include/asm-sh/system.h
> > +++ b/include/asm-sh/system.h
> > @@ -7,6 +7,7 @@
> >   */
> >  
> >  #include <linux/irqflags.h>
> > +#include <linux/compiler.h>
> >  #include <asm/types.h>
> >  
> >  /*
> 
> 
> Yes it is fixed, thank you!
> 
GCC4 inlining strikes again.. :-)

Re: GCC-4 problems

[Paul M. <pau...@re...>]

On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> Also, these exports need to be removed from sh_ksyms.c, they give
> "undefined reference" errors:
> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> 
Ok, so removing these seems to be have created fallout all over the
place. Apparently it's just your GCC4 that seems to have problems with
these symbols, whereas the other ones really seem to want them. It looks
like we're going to have to narrow it down to the exact release in which
they vanished (I would guess 4.1.2, since 4.1.1 still wants them).

akpm also suggests he has a 3.4.5 toolchain that needs these, which is
also very unusual. Do you have a tarball of your compiler somewhere so
it's easier to debug?

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Paul Mundt wrote:
> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>> Also, these exports need to be removed from sh_ksyms.c, they give
>> "undefined reference" errors:
>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>
> Ok, so removing these seems to be have created fallout all over the
> place. Apparently it's just your GCC4 that seems to have problems with
> these symbols, whereas the other ones really seem to want them. It looks

Oh, sorry, that wasn't my intention at all.

> like we're going to have to narrow it down to the exact release in which
> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> 
> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> also very unusual. Do you have a tarball of your compiler somewhere so
> it's easier to debug?

Prompted by your mail I reverted commit
9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
just fine now; the only difference is that I've upgraded from 4.1.1 to 4.1.2
in the meantime.

Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
(see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)

I can rebuild gcc-4.1.1 which failed for me if you like.

Thank you,

	Manuel Lauss

Re: GCC-4 problems

[Mike F. <va...@ge...>]

On Saturday 07 July 2007, Manuel Lauss wrote:
> Paul Mundt wrote:
> > On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> >> Also, these exports need to be removed from sh_ksyms.c, they give
> >> "undefined reference" errors:
> >> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> >
> > Ok, so removing these seems to be have created fallout all over the
> > place. Apparently it's just your GCC4 that seems to have problems with
> > these symbols, whereas the other ones really seem to want them. It looks
>
> Oh, sorry, that wasn't my intention at all.
>
> > like we're going to have to narrow it down to the exact release in which
> > they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> >
> > akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> > also very unusual. Do you have a tarball of your compiler somewhere so
> > it's easier to debug?
>
> Prompted by your mail I reverted commit
> 9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
> just fine now; the only difference is that I've upgraded from 4.1.1 to
> 4.1.2 in the meantime.
>
> Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
> 4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
> (see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)
>
> I can rebuild gcc-4.1.1 which failed for me if you like.

ruh roh ... someone said Gentoo ;)

default gcc-4.x in Gentoo enables multilib for SuperH targets akin to gcc-3=
=2Ex=20
(since vanilla gcc-4.x does not include nofpu support by default)

to doubly verify, you can emerge gcc with USE=3Dvanilla ... that'll disable=
 the=20
Gentoo patchset ...
=2Dmike

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Mike Frysinger wrote:
> On Saturday 07 July 2007, Manuel Lauss wrote:
>> Paul Mundt wrote:
>>> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>>>> Also, these exports need to be removed from sh_ksyms.c, they give
>>>> "undefined reference" errors:
>>>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>> Ok, so removing these seems to be have created fallout all over the
>>> place. Apparently it's just your GCC4 that seems to have problems with
>>> these symbols, whereas the other ones really seem to want them. It looks
>> Oh, sorry, that wasn't my intention at all.
>>
>>> like we're going to have to narrow it down to the exact release in which
>>> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
>>>
>>> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
>>> also very unusual. Do you have a tarball of your compiler somewhere so
>>> it's easier to debug?
>> Prompted by your mail I reverted commit
>> 9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
>> just fine now; the only difference is that I've upgraded from 4.1.1 to
>> 4.1.2 in the meantime.

That was bogus; I was compiling the wrong local tree again.

>> Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
>> 4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
>> (see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)
>>
>> I can rebuild gcc-4.1.1 which failed for me if you like.
> 
> ruh roh ... someone said Gentoo ;)
> 
> default gcc-4.x in Gentoo enables multilib for SuperH targets akin to gcc-3.x 
> (since vanilla gcc-4.x does not include nofpu support by default)
> 
> to doubly verify, you can emerge gcc with USE=vanilla ... that'll disable the 
> Gentoo patchset ...

Did that, it still complains:
arch/sh/kernel/built-in.o:(__ksymtab+0xa8): undefined reference to `__sdivsi3_i4i'
arch/sh/kernel/built-in.o:(__ksymtab+0xb0): undefined reference to `__udiv_qrnnd_16'
arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to `__udivsi3_i4i'

...and the "-m4-nofpu" option is unsupported again ;-)

I'm going to try with vanilla binutils next...

Thanks,
	Manuel Lauss

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Paul Mundt wrote:
> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>> Also, these exports need to be removed from sh_ksyms.c, they give
>> "undefined reference" errors:
>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>
> Ok, so removing these seems to be have created fallout all over the
> place. Apparently it's just your GCC4 that seems to have problems with
> these symbols, whereas the other ones really seem to want them. It looks
> like we're going to have to narrow it down to the exact release in which
> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> 
> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> also very unusual. Do you have a tarball of your compiler somewhere so
> it's easier to debug?

__udiv_qrnnd_16 was introduced by this GCC PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014

I'll test 4.2.0 next.

Thanks,
	Manuel Lauss

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Manuel Lauss wrote:
> Mike Frysinger wrote:
>> On Saturday 07 July 2007, Manuel Lauss wrote:
>>> Paul Mundt wrote:
>>>> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>>>>> Also, these exports need to be removed from sh_ksyms.c, they give
>>>>> "undefined reference" errors:
>>>>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>>> Ok, so removing these seems to be have created fallout all over the
>>>> place. Apparently it's just your GCC4 that seems to have problems with
>>>> these symbols, whereas the other ones really seem to want them. It looks
>>> Oh, sorry, that wasn't my intention at all.
>>>
>>>> like we're going to have to narrow it down to the exact release in which
>>>> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
>>>>
>>>> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
>>>> also very unusual. Do you have a tarball of your compiler somewhere so
>>>> it's easier to debug?
>>> Prompted by your mail I reverted commit
>>> 9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
>>> just fine now; the only difference is that I've upgraded from 4.1.1 to
>>> 4.1.2 in the meantime.
> 
> That was bogus; I was compiling the wrong local tree again.
> 
>>> Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
>>> 4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
>>> (see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)
>>>
>>> I can rebuild gcc-4.1.1 which failed for me if you like.
>> ruh roh ... someone said Gentoo ;)
>>
>> default gcc-4.x in Gentoo enables multilib for SuperH targets akin to gcc-3.x 
>> (since vanilla gcc-4.x does not include nofpu support by default)
>>
>> to doubly verify, you can emerge gcc with USE=vanilla ... that'll disable the 
>> Gentoo patchset ...
> 
> Did that, it still complains:
> arch/sh/kernel/built-in.o:(__ksymtab+0xa8): undefined reference to `__sdivsi3_i4i'
> arch/sh/kernel/built-in.o:(__ksymtab+0xb0): undefined reference to `__udiv_qrnnd_16'
> arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to `__udivsi3_i4i'
> 
> ...and the "-m4-nofpu" option is unsupported again ;-)
> 
> I'm going to try with vanilla binutils next...

and that didn't change anything either.  So the question is what gcc version and
patches is everyone else using where the above mentioned symbols ARE exported?

Thanks,
	Manuel Lauss

Re: GCC-4 problems

[Mike F. <va...@ge...>]

On Saturday 07 July 2007, Manuel Lauss wrote:
> Manuel Lauss wrote:
> > Did that, it still complains:
> > arch/sh/kernel/built-in.o:(__ksymtab+0xa8): undefined reference to
> > `__sdivsi3_i4i' arch/sh/kernel/built-in.o:(__ksymtab+0xb0): undefined
> > reference to `__udiv_qrnnd_16'
> > arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to
> > `__udivsi3_i4i'
> >
> > ...and the "-m4-nofpu" option is unsupported again ;-)
> >
> > I'm going to try with vanilla binutils next...
>
> and that didn't change anything either.  So the question is what gcc
> version and patches is everyone else using where the above mentioned
> symbols ARE exported?

maybe some fundamental checks first ... how are you invoking crossdev ?  ca=
n=20
you post the output of `sh4-unknown-linux-gnu-gcc -v` ?
=2Dmike

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Manuel Lauss wrote:
> Paul Mundt wrote:
>> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>>> Also, these exports need to be removed from sh_ksyms.c, they give
>>> "undefined reference" errors:
>>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>>
>> Ok, so removing these seems to be have created fallout all over the
>> place. Apparently it's just your GCC4 that seems to have problems with
>> these symbols, whereas the other ones really seem to want them. It looks
>> like we're going to have to narrow it down to the exact release in which
>> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
>>
>> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
>> also very unusual. Do you have a tarball of your compiler somewhere so
>> it's easier to debug?
> 
> __udiv_qrnnd_16 was introduced by this GCC PR:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
> 
> I'll test 4.2.0 next.

Confirmed, 4.2.0 does not complain about undefined references.

So maybe those defines should be made dependent on gcc >= 4.2 ?
Although that wouldn't solve akpm's Problem with 3.4..

Thanks,
	Manuel Lauss

Re: GCC-4 problems

[Paul M. <pau...@re...>]

On Sat, Jul 07, 2007 at 02:26:56PM +0200, Manuel Lauss wrote:
> Manuel Lauss wrote:
> > Paul Mundt wrote:
> >> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> >>> Also, these exports need to be removed from sh_ksyms.c, they give
> >>> "undefined reference" errors:
> >>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> >>>
> >> Ok, so removing these seems to be have created fallout all over the
> >> place. Apparently it's just your GCC4 that seems to have problems with
> >> these symbols, whereas the other ones really seem to want them. It looks
> >> like we're going to have to narrow it down to the exact release in which
> >> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> >>
> >> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> >> also very unusual. Do you have a tarball of your compiler somewhere so
> >> it's easier to debug?
> > 
> > __udiv_qrnnd_16 was introduced by this GCC PR:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
> > 
> > I'll test 4.2.0 next.
> 
> Confirmed, 4.2.0 does not complain about undefined references.
> 
> So maybe those defines should be made dependent on gcc >= 4.2 ?
> Although that wouldn't solve akpm's Problem with 3.4..
> 
Well, these symbols also exist in the ST compiler, which is on 4.1.1. So
we probably have to special case for that.

It looks like we're just going to have to include these symbols in the
kernel directly in arch/sh/lib if we want to support this generically.
I'll hack something up this week.

Re: GCC-4 problems

[Paul M. <le...@li...>]

On Sat, Jul 07, 2007 at 02:26:56PM +0200, Manuel Lauss wrote:
> Manuel Lauss wrote:
> > Paul Mundt wrote:
> >> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> >>> Also, these exports need to be removed from sh_ksyms.c, they give
> >>> "undefined reference" errors:
> >>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> >>>
> >> Ok, so removing these seems to be have created fallout all over the
> >> place. Apparently it's just your GCC4 that seems to have problems with
> >> these symbols, whereas the other ones really seem to want them. It looks
> >> like we're going to have to narrow it down to the exact release in which
> >> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> >>
> >> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> >> also very unusual. Do you have a tarball of your compiler somewhere so
> >> it's easier to debug?
> > 
> > __udiv_qrnnd_16 was introduced by this GCC PR:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
> > 
> > I'll test 4.2.0 next.
> 
> Confirmed, 4.2.0 does not complain about undefined references.
> 
> So maybe those defines should be made dependent on gcc >= 4.2 ?
> Although that wouldn't solve akpm's Problem with 3.4..
> 
Ok, so apparently I'm an idiot and should have just read the
lib1funcs.S from the beginning ;-)

These symbols are all FP users, so if they're legitimately emitted for
the kernel, that's a problem. It looks like some people have papered
around this by inlining integer equivalents in arch/<foo>/lib, but it's
more indicative of CFLAGS brain-damage.

I tried reproducing the problem with akpm's compiler, and the end result
was that -m4-nofpu wasn't being specified on account of -m4a-nofpu not
being available (and CONFIG_CPU_SH4A cflags trumps CONFIG_CPU_SH4). As
soon as that was fixed up, these were no longer emitted by the compiler.

So the answer seems to be to just leave them out of the kernel and
possibly throw up an entry on the wiki explaining all of this so we don't
have the same thing happen next year after having forgotten the
rationale again.

--

diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index c7a8e1f..77fecc6 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -35,12 +35,12 @@ endif
 endif
 
 cflags-$(CONFIG_CPU_SH2)		:= $(call cc-option,-m2,)
-cflags-$(CONFIG_CPU_SH2A)		:= $(call cc-option,-m2a,) \
+cflags-$(CONFIG_CPU_SH2A)		+= $(call cc-option,-m2a,) \
 					   $(call cc-option,-m2a-nofpu,)
 cflags-$(CONFIG_CPU_SH3)		:= $(call cc-option,-m3,)
 cflags-$(CONFIG_CPU_SH4)		:= $(call cc-option,-m4,) \
 	$(call cc-option,-mno-implicit-fp,-m4-nofpu)
-cflags-$(CONFIG_CPU_SH4A)		:= $(call cc-option,-m4a,) \
+cflags-$(CONFIG_CPU_SH4A)		+= $(call cc-option,-m4a,) \
 					   $(call cc-option,-m4a-nofpu,)
 
 cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -mb

ST compiler silliness

[Paul M. <le...@li...>]

On Thu, Jul 12, 2007 at 08:53:25AM +0900, Paul Mundt wrote:
> On Sat, Jul 07, 2007 at 02:26:56PM +0200, Manuel Lauss wrote:
> > Manuel Lauss wrote:
> > > Paul Mundt wrote:
> > >> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> > >>> Also, these exports need to be removed from sh_ksyms.c, they give
> > >>> "undefined reference" errors:
> > >>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> > >>>
> > >> Ok, so removing these seems to be have created fallout all over the
> > >> place. Apparently it's just your GCC4 that seems to have problems with
> > >> these symbols, whereas the other ones really seem to want them. It looks
> > >> like we're going to have to narrow it down to the exact release in which
> > >> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> > >>
> > >> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> > >> also very unusual. Do you have a tarball of your compiler somewhere so
> > >> it's easier to debug?
> > > 
> > > __udiv_qrnnd_16 was introduced by this GCC PR:
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
> > > 
> > > I'll test 4.2.0 next.
> > 
> > Confirmed, 4.2.0 does not complain about undefined references.
> > 
> > So maybe those defines should be made dependent on gcc >= 4.2 ?
> > Although that wouldn't solve akpm's Problem with 3.4..
> > 
> Ok, so apparently I'm an idiot and should have just read the
> lib1funcs.S from the beginning ;-)
> 
> These symbols are all FP users, so if they're legitimately emitted for
> the kernel, that's a problem. It looks like some people have papered
> around this by inlining integer equivalents in arch/<foo>/lib, but it's
> more indicative of CFLAGS brain-damage.
> 
> I tried reproducing the problem with akpm's compiler, and the end result
> was that -m4-nofpu wasn't being specified on account of -m4a-nofpu not
> being available (and CONFIG_CPU_SH4A cflags trumps CONFIG_CPU_SH4). As
> soon as that was fixed up, these were no longer emitted by the compiler.
> 
Even better, we have two different problems with the same set of
symbols.. This is getting almost comical.

akpm's compiler was related to generation of __udivsi3_i4 and
__sdivsi3_i4 (FP) references, whereas the ST compiler emits __udivsi3_i4i
and __sdivsi3_i4i, which are integer variants, and therefore reasonable.

The previous patch takes care of the FP variants, but we still require
the explicit symbol export for the integer ones, and there doesn't seem
to be any sane way to determine whether we're on the ST compiler or not.

This means we're still forced to add the _i4i variants to arch/sh/lib,
though unfortunately the integer variants in the ST compiler all assume
that we're on an SH-4, and so won't work for the common case either. The
compiler versions are optimized as well, and I have no interest in
merging the massive divisor lookup tables that go along with it either.

So this leaves us with having to hack up a generic C variant for those
two symbols, looking at gcc --version for the ST string and setting a
define based on that so we can conditionally export the _i4i symbols, or
nm'ing libgcc. And better than that, neither cc-version nor any of the
-dump flags give any meaningful indicator to differentiate the ST
compiler from a stock gcc4. All of these options suck rather profoundly.

Since gcc 4.2 seems to support them, the exports likely have to be
special cased just for the ST compiler on gcc 4.1.x, so stock 4.1.x
doesn't inadvertently break. Brilliant.