Subject: Re: gcc 3.3.1 fixes
To: None <tech-toolchain@netbsd.org, port-sh3@netbsd.org>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: tech-toolchain
Date: 08/12/2003 02:05:11
On Wed, Jul 30, 2003 at 14:38:49 +0400, Valeriy E. Ushakov wrote:

> I'm trying to build hpcsh with the new gcc 3.3.1.  Can someone please
> review the changes I had to do.
[...]
> 1. NO_PROFILE_COUNTERS [...]

Committed.


> 2. const in ASM_OUTPUT_LABELREF - w/out it the build dies with
>    "discard qualifiers" warning/error.

Committed.


> 3. the rest is the RETURN_ADDR_RTX changes (done after alpha and mmix).

Committed.  I have redone this fix by pulling the same change from
gcc-current.


> I've almost successfully completed the hpcsh build (MKPROFILE=no) with
> the last two changes in my tree.  The only problem was:
> 
> /nb/src/gnu/dist/gcc/gcc/function.c: In function `assign_parms':
> /nb/src/gnu/dist/gcc/gcc/function.c:4740: warning: `and' of mutually exclusive equal-tests is always 0
> 
> Which I fail to understand, as the only && in that condition seems to
> be TARGET_SHMEDIA that expands to:
> 
>     (target_flags & SH5_BIT) && !(target_flags & SH1_BIT)

This one still exists.


Other than that one glitch the word compiles cleanly.  However some of
the resulting binaries behave strangely.  E.g. mv(1) will always fail
with "out of memory", ksh will dump core, sshd will complain that
there's no userfor privilege separation, etc. I have tracked it down
to this:

If gcc needs to do an integer division it will emit a call to
__udivsi3, but it will *NOT* mark scratch registers as clobbered by
that call.  So it will happily use scratch registers to keep values
across the call to __udivsi3 (r2 in the mv(1) case I used to debug
this).

The problem is that __udivsi3 is in libc, so it gets linked
dynamically.  If __udivsi3 is linked statically all is ok, as it
doesn't touch any of the scratch registers.  But a call into libc.so
__udivsi3 will clobber them on it's way through dynamic linker, I
guess.

To verify that theory I put udivsi3.o from libc.a into libgcc.a and
relinked few failing binaries - and they worked ok.

I wonder what is a proper solution for this?

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen