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


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