This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc corrections for better pie support


Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Richard Sandiford wrote:
>> 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.

Executables are created from position-independent objects, but the
executables themselves are not PIC.  They have a fixed load address
and are not relocatable.  Hence...

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

...I don't agree.  non-PIE (in the -fno-PIE sense) is the default for
mips*-linux-gnu, just as it is for other platforms.

Long term, I think we'd like to have a situation in which the individual
objects of an executable use a non-PIC brand of abicalls, thus avoiding
GOT accesses for locally-binding symbols, etc.  Perhaps that's what you
meant in your last point.

The question then is: how would such a mode be selected?  I personally
think it should be default if the user doesn't explicitly ask for PIC
(i.e. doesn't use -fpic/-fPIC/-fpie/-fPIE).  This is what other targets
do, and gcc ought to provide a consistent interface where possible.

Hence my question above.  Should __PIC__ be defined in the non-PIC
abicalls mode?  (Which, in my scheme, would mean when no -fpic/...
option is specified.)  I agree with you that it would be more logical
not to define it (option (1) in my earlier message) but:

  (a) I fear that most current MIPS-specific uses of __PIC__ really mean
      "abicalls".  For example, if you have:

              jal     foo

      where foo is a library function, you still need to use the abicalls
      sequence to call foo.  And at the moment, if a particular bit of user
      asm has __PIC__ and non-__PIC__ versions, I suspect only the __PIC__
      version will set up $gp.

  (b) Code guarded by __PIC__ would still work in the non-PIC abicalls
      mode too, it would just be less optimal.

So I think we're stuck with __PIC__ == abicalls for now...

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

Like I say, -fno-pie is effectively the default (in the sense that
executables are not relocatable by default).  It would seem strange
to have an explicit -fno-pie do something different.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]