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: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 8 Nov 2004 23:28:02 +0100 (CET)
- Subject: Re: gcc corrections for better pie support
On Mon, 8 Nov 2004, Jakub Jelinek wrote:
> On Mon, Nov 08, 2004 at 09:30:17PM +0100, Peter S. Mazinger wrote:
> > It's not likely to have DT_TEXTREL, it's sure that it will end up w/
> > DT_TEXTREL, more likely than -shared -fno-pic, try any small shared lib.
>
> I don't think so.
> -fno-pic tells the compiler:
> 1) exported (== non-static non-hidden) routines defined in the current
> CU will not be overridden
> 2) the code doesn't need to be position independent
> -f{pie,PIE} tells the compiler:
> 1) exported (== non-static non-hidden) routines defined in the current
> CU will not be overridden
> 2) the code must be position independent
> -f{pic,PIC} tells the compiler:
> 1) exported (== non-static non-hidden) routines defined in the current
> CU may still be overridden
> 2) the code must be position independent
>
> So, if you have code like:
> void foo (void) { } int bar (void) { foo (); return 0; }
> then -shared {-fno-pic,-fpie,-fPIE} might result in DT_TEXTREL,
> as the compiler can assume foo is not overridden (e.g. on i386 can
> use call foo instead of call foo@plt).
>
> But if you have say:
> extern int i;
> int baz (void) { return i; }
> then -shared -fno-pic will likely be DT_TEXTREL, while -shared -fpie
> will compile be ok.
I do not know C, so sorry, I don't understand the above ;-(
>
> So please explain where you find the "more likely" above.
from gcc/opts.c
if (flag_pie)
flag_pic = flag_pie;
if (flag_pic && !flag_pie)
flag_shlib = 1;
if they would override each other the above test would be pointless.
the above means for me: if -fpic is defined w/o -fpie only than a shared
lib is built.
> > You should look into the code, the code says to me, that the
> > resulting object won't be used in shared libs, specifically the part
> > where a check is done to see if both -fpic and -fpie are set.
>
> -fno-pic/-fpic/-fPIC/-fpie/-fPIE are supposed to override each other,
> the last one on the command line ought to win.
>
> > > > > 4. correction of the HAVE_LD_PIE logic, if binutils' ld does not support
> > > > > -pie, then pie is useless, so added ifdefs to endfile section too and
> > > > > removed the usage of *S.o in startfile too.
> > >
> > > Why? Linking PIC code into normal executables works.
> >
> > why the PIC overhead if unneeded (we can't use it, because ld does not
> > support -pie), and why should we use combinations like
> > crtbegin.o w/ crtendS.o or crtbeginS.o w/ crtend.o?
>
> Well, if you know your linker doesn't support -pie but use -pie anyway, you
> can pay the couple of cycles for it, can't you. The overhead is just a few
> relocations, nothing terrible.
Do all the users know/or are aware of that?
You have added %{pie:} to the ld section some time ago, if HAVE_LD_PIE is
not defined? Why that? We allow the user to believe he built pie, w/o
informing him that it faiied.
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