Mips/Linux integration of latest GCC, Binutils & GLibc
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Tim Wilkinson
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).
Quoted 8 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line
Quoted 1 line
Okay this makes sense. This then means there's a problem with GLIBC
since it
Quoted 3 lines
Quoted 3 lines
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
Quoted 3 lines
Quoted 3 lines
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
Quoted 5 lines
Quoted 3 lines
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
Quoted 6 lines
the last time I sent it to him.
Quoted 4 lines
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)
Quoted 1 line
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 6 lines · Jay Carlson
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.
Quoted 6 lines
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
Quoted 10 lines · Tim Wilkinson
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.
Quoted 5 lines
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.
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.
Ralf