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

So please explain where you find the "more likely" above.

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

	Jakub


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