This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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