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


On Wed, 10 Nov 2004, Richard Sandiford wrote:

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

This is not quite true, I have access to a mips box running uclibc and I 
can build PIE executables, these are relocatable (I know though that such 
test can't be done on glibc, because it fails w/ undefs)
 
> >  - 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.

it's not gas/ld problem, it's probably glibc that strikes (as I said, it 
works on uclibc) maybe the check for .init_array is incorrect/incomplete

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

you are right, forget about fno-PIE/fno-pie.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2


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