Re: gcc corrections for better pie support

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

Richard Sandiford wrote:
[snip]
> > 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.

I see. So what I meant would be non-PIC + non-PIE.

[snip]
> 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.

Yes, this seems to be likely.

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

I agree.


Thiemo