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

From: Ralf Baechle <[email-masked]>
Date: Wed, 8 Mar 2000 17:42:51 -0300

On Wed, Mar 08, 2000 at 07:11:16PM +0000, Tim Wilkinson wrote:

> So here's my basic problem.  GCC, Binutils and GLIBC don't really agree about
> PIC nature of code.  GCC seems to default to PIC unless you say -no-pic, but
> even then doesn't remove the -KPIC flag to the assembler.  GLIBC requires the
> PIC symbol to be defined otherwise it uses non-pic assembly code which won't
> compile with the -KPIC flag to the assembler (there are also a bunch of
> linux/glibc compatiblity issues we won't get into right now).
> 
> So my questions is - should GCC by default generate non-pic code or should it
> generate PIC code by default?  If it generate PIC by default it needs to
> define PIC and __PIC__ ... but this will cause problems when building a
> static version of GLIBC (even though it's really a PIC version).
> 
> I would want to do the following - gcc by default doesn't build PIC code,
> fix the -KPIC flag to be passed only when generating PIC code, and make a
> few minor changes to GLIBC to allow all this to happen.

You cannot mix pic and non-pic code on MIPS, so it must generate PIC code
by default and that is also pass PIC / __PIC__ / -KPIC by default.  That's
what the real compilers (not the abortion in egcs-cvs) do.

That is static vs shared and pic vs. non-pic code are orthogonal issues
except that you cannot generate shared libs from non-pic code.  They
always have been except that the way things are handled on other
architectures doesn't make recognizing this fact very important.

  Ralf

---

From: "Jay Carlson" <[email-masked]>
Date: Wed, 8 Mar 2000 17:25:18 -0500

> > Okay this makes sense.  This then means there's a problem with GLIBC
since it
> > excludes certain files when building a static library but unfortuantely
> > needs them because it uses #ifdef PIC to include bits of code related to
> > shared library workings (essentially it considers PIC to mean SHARED
when
> > this may not infact be the case - not for MIPS anyway).
> >
> > So what you're saying is pretty much how I have my gcc, binutils and
glibc
> > set up - I introduced a -DSHARED to glibc (which I suspect isn't really
> > okay) when building shared libraries so static libraries didn't include
> > the bad code.  I may look for a better solution however.
>
> Indeed.  The problem is just that Ulrich drepper didn't accept such a
patch
> the last time I sent it to him.
>
> > I've also made a bunch of elf related changes to mips/linux so that the
> > assembler output from gcc is more like the elf output for the x86/linux
> > targets.  It's interesting to note that mips/linux doesn't even defined
> > linux for CPP (and doesn't do a bunch of other stuff either come to
that)
> > which confused things no end when compiling the linux kernel.

The mips-linux configuration in gcc 2.95.x out of the box is just awful.  It
was obviously never tested against a full rebuild of the system, or in fact
any significant rebuild.

> Go to oss.sgi.com and get /pub/linux/mips/src/egcs/egcs-1.0.3a-2.diff.gz
> and integrate that with a current egcs.  This is what most people are
> using and is known to work.  It generates assembler output that is known
> to be working with binutils and even halfway human-readable as far as this
> can be said from compiler output.  You'll also find binutils test patches
> for more current releases there.

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...

I did a port/translation/reinterpretation of Ralf's configuration in
egcs-1.0.3a-2 for gcc 2.95.1.  My take on this, as expressed in
ftp://ftp.place.org/pub/nop/linuxce/gcc-2.95.1-interim-990916.patch.gz , is
that gcc should always build as PIC, unless some Makefile etc really does
want to ask for the non-PIC lossage.

The primary flag for controlling this in my config
is -mabicalls/-mno-abicalls.  -mabicalls is the default (as it was in Ralf's
config).  -D__PIC__ and -D__pic__ are asserted unless -mno-abicalls is set
(which also implies -fno-pic).   glibc is happy with this.  So is the
kernel.  And random makefiles, libtool, autoconf, etc, can happily build
with their bogus -fpic or -fPIC options from other platforms and not break
anything.

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 :-(

Jay

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 8 Mar 2000 19:59:46 -0300

On Wed, Mar 08, 2000 at 05:25:18PM -0500, Jay Carlson wrote:

> 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.

> 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

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 9 Mar 2000 10:10:19 -0800

On Wed, Mar 08, 2000 at 08:55:17PM +0000, Tim Wilkinson wrote:

> Okay this makes sense.  This then means there's a problem with GLIBC since it
> shared library workings (essentially it considers PIC to mean SHARED when
> So what you're saying is pretty much how I have my gcc, binutils and glibc

Indeed.  The problem is just that Ulrich drepper didn't accept such a patch
the last time I sent it to him.

> linux for CPP (and doesn't do a bunch of other stuff either come to that)

  Ralf