ppc-linux gcc configury patch

[Geoff Keating]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Mon, 31 May 1999 21:59:36 +0200
> Cc: Cort Dougan <cort@ppc.kernel.org>, egcs-patches@egcs.cygnus.com,
>         geoffk@ozemail.com.au
> 
> Am Mon, 31 May 1999 schrieb Richard Henderson:
> >On Mon, May 31, 1999 at 06:04:59PM +0200, Franz Sirl wrote:
> >> Well, just to reinstate, gcc-2.95 needs a binutils snapshot (or,
> >> with some restrictions, binutils >= 2.9.1.0.23) to _build_, even
> >> without without your patches, both on powerpc-linux-gnu and
> >> powerpc-linux-gnulibc1.
> >
> >Ok.  In which case I'll put in the rs6000/linux.h one liner without
> >the associated configury.
> 
> Uh, oh, I just took a look at the changes in binutils and wanted to
> ask if you did clear this change with Geoff?

> AFAIK changing TEXT_START_ADDR from 0x01800000 to 0x10000000 will
> break quite a few assumptions in glibc-2.1 and slow down calls to
> shared libs cause they are no longer loaded in an area reachable by
> PPC's 26bit offset branch instructions :-(. I can't believe Geoff
> accepted such a performance penalty without accompanying changes in
> glibc-2.1.

I think glibc will cope.  You may want to check with ldd, make sure
that libraries are loaded just underneath the executable.  glibc
already has to cope with even earlier executables which are loaded at
0x40000, which is much more annoying.

However, be aware that I've tried 0x40000, 0x02000000, and 0x01800000,
and the last was the best.  The reason high addresses weren't so good
is that they make it impossible for an executable to jump to location
0, which happens when you have undefined weak symbols.

You might try this test case:  take the attached files, and:

gcc -O -fpic so1.c -Wl,-h,so.so -shared -o so.so.1
gcc -O -fpic so2.c -Wl,-h,so.so -shared -o so.so.2
gcc -O program.c so.so.1 -o program1
gcc -O program.c so.so.2 -o program2
ln -sf so.so.1 so.so
LD_LIBRARY_PATH=. ./program1
LD_LIBRARY_PATH=. ./program2
ln -sf so.so.2 so.so
LD_LIBRARY_PATH=. ./program1
LD_LIBRARY_PATH=. ./program2

I get a core dump on the second-last one, which is somewhat annoying
(but not fatal, it just means you need to re-link in some
circumstances); I suspect you'll get link errors linking program2,
which is worse.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>


===File /tmp/program.c======================================
extern void foo(void);
asm (".weak foo");
int main(void)  { if (&foo) foo(); }
============================================================

===File /tmp/so1.c==========================================
asm (".weak foo");
void foo(void) { ; }
============================================================

===File /tmp/so2.c==========================================
/* nothing in this file.  In particular, no 'foo'! */
============================================================