linux-mips-fnet
[Top] [All Lists]

Re: Mips/Linux integration of latest GCC, Binutils & GLibc

To: Jay Carlson <nop@nop.com>
Subject: Re: Mips/Linux integration of latest GCC, Binutils & GLibc
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Wed, 8 Mar 2000 19:59:46 -0300
Cc: Tim Wilkinson <tim@transvirtual.com>, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@engr.sgi.com
In-reply-to: <59c501bf894d$31be85c0$0a00000a@decoy>
References: <38C54F05.458A3EFE@transvirtual.com> <20000308140301.B1425@uni-koblenz.de> <38C6A5D4.F08DFCE4@transvirtual.com> <20000308174251.A6399@uni-koblenz.de> <38C6BE35.C58B0630@transvirtual.com> <20000308180850.D6399@uni-koblenz.de> <59c501bf894d$31be85c0$0a00000a@decoy>
On Wed, Mar 08, 2000 at 05:25:18PM -0500, Jay Carlson wrote:

> As Ralf sez, because MIPS PIC and non-PIC code can't intercall, generation
> of non-PIC code for use in static libraries is incorrect, unless
> EVERYTHING you're linking is non-PIC.  Most people feel that giving up
> shared libraries is too high a price for the potential gain in code
> density and efficiency from non-PIC/non-ABI builds.  Me, I still have
> lingering doubts, but I don't have working code yet, so...

Even if just two programs are sharing libc you're already on the winning
side.

> Originally I thought that it would not be necessary to ever pass -KPIC to
> the assembler; at the top of each PIC/abicalls assembly file GCC produces,
> it sticks in a ".abicalls" directive which has the same effect as the
> -KPIC option.  That worked just great until I encountered .S files that
> didn't have that directive and didn't know any better, so I had to put the
> -KPIC back in :-(

We've got assembler files that without any change can be assembled both into
pic and non-pic code, so the caller of the assembler should handle this.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>