gcc corrections for better pie support

[Thiemo Seufer]

Richard Sandiford wrote:
> "Peter S. Mazinger" <ps.m@gmx.net> writes:
> > On Tue, 9 Nov 2004, Richard Sandiford wrote:
> >> flag_shlib || flag_pie should make sure that the macros are only
> >> defined if -fpic/-fPIC/-fpie/-fPIE are passed.
> >
> > that would change the current behaviour, where it was defined all the 
> > time and that would mean some trouble with apps (all that checked 
> > for __PIC__ and -fPIC was not used in CFLAGS)
> 
> Yeah, I know, but...
> 
> This is just such a rat's nest.  The problem is that -fno-pic doesn't
> achieve anything on its own.  It gets unconditionally overridden by
> the MIPS options handling code unless you also specify -mno-abicalls.
> And if you specify -mno-abicalls, then -fno-pic is redundant, because
> the MIPS port no longer has any form of non-abicalls PIC (embedded PIC
> having been removed, and never having being an issue for GNU/Linux anyway).

I herewith declare non-abicalls PIC to be completely irrelevant for
MIPS linux. :-)

> So the current handling of __PIC__ is inconsistent.  What does it mean
> for mips*-linux-gnu targets?  Does it mean:
> 
>    (1) That position independent code has been explicitly selected?
>        If so, then flag_pie || flag_shlib seems like the right condition.
> 
>    (2) That abicalls code is selected?  If so, then the current specs are
>        wrong, because "gcc -fno-pic" generates abicalls code.
> 
> But I suppose the current definition is closest to (2).  If (2) is indeed
> what we want, then another alternative would be to guard the __PIC__
> definition in linux.h with TARGET_ABICALLS.

Currently in use on MIPS linux are:
 - PIC + abicalls for the whole userland. __PIC__ is always expected to
   be defined. Executables are always PIC. This is the toolchain default.
 - non-PIC + no-abicalls for all kernels. __PIC__ isn't checked for, but
   defining it would look odd.

In future, we _may_ also be interested in
 - non-PIE + abicalls for executables. __PIC__ shouldn't be defined in
   that case. This is currently unsupported by the toolchain.

We don't have to fully preserve current behaviour, but at least the
current userland assumptions should remain unchanged.

> >> >> > @@ -123,7 +121,7 @@
> >> >> >  #define SUBTARGET_ASM_SPEC "\
> >> >> >  %{mabi=64: -64} \
> >> >> >  %{!fno-PIC:%{!fno-pic:-KPIC}} \
> >> >> > -%{fno-PIC:-non_shared} %{fno-pic:-non_shared}"
> >> >> > +%{fno-PIC|fno-pic:-non_shared}"
> >> >> 
> >> >> If this is causing trouble, you should be able to get rid of all the
> >> >> PIC stuff here too.  GAS assumes -non_shared by default and GCC uses
> >> >> .abicalls if it wants -KPIC.
> >> 
> >> Sorry, just ignore this comment.  I was thinking only about gcc's use
> >> of the assembler.
> >> 
> >> We need to pass -KPIC by default when using the gcc driver to assemble
> >> user .S and .s files, so we do need to keep the existing options.
> >
> > so -non_shared could go away and I think the other one would be more 
> > correct as
> > %{!fno-PIC:%{!fno-pic:%{!fno-PIE:%{!fno-pie:-K PIC}}}}
> 
> No space between -K and PIC.  But what effect do you want -fno-pie to have?

Currently none at all, because gas/ld don't support it yet.

> The change you suggest means that:
> 
>    gcc -S foo.S
>    gcc -S -fno-pie bar.S
>    gcc foo.o bar.o
> 
> might fail.  foo.o will use abicalls and, unless it has an explicit
> .abicalls directive, bar.o won't.  Is that what you want?

I would say this behaviour is correct (as soon as gas supports non-PIE,
and handles also a .noabicalls directive). Otherwise all calls in the
executable over compilation unit borders would need to go through the
got. This looks reasonable for compiled code, but hand-written assembly
should be allowed to use an optimization. Introducing non-PIE for
mips will usually require changes to such assembly code anyway.


Thiemo