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
- From: "Peter S. Mazinger" <ps dot m at gmx dot net>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>,Zack Weinberg <zack at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 10 Nov 2004 12:41:15 +0100 (CET)
- Subject: 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