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.