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 12:17:10AM +0100, Peter S. Mazinger wrote:
> > What this patch corrects/offers:
> > 
> > 1. startfile/endfile usage problem
> > If more then one of the flags shared/static/pie are used, we could end up 
> > w/ 2 startfiles or endfiles, or use the false ones

I think GCC should just disallow -shared -static etc.

%{shared:%{static:%e-shared and -static options are incompatible}
%{pie:%{static:%e-pie and -static options are incompatible}
%{shared:%{pie:%e-shared and -pie options are incompatible}

> > 3. the cc1 options patch parts blocks some incompat flags, like using 
> > -fPIE and -shared (the dyn lib will surely end up w/ TEXTREL, test-case 
> > zlib <= 1.2.1.1) or -pg/-p/-profile along w/ -pie, useless unless we 
> > have a profiling -pie compliant implementation of gcrt1.o

I think this is wrong.
There are architectures that allow DT_TEXTREL shared libraries and if you don't
error on say -shared and missing -fpic/-fPIC (which could similarly result
in DT_TEXTREL, but shouldn't be errored on, as -shared is a switch for
linking while -fpic etc. are for compiling), I don't see why you should
particularly moan about -shared -fpie.  It is far less likely that you'll
have DT_TEXTREL with -shared -fpie than when you use -shared -fno-pic.
But in practice you first compile some objects and then link things together
and what flags you used is not recorded anywhere.

On architectures where non-pic code in shared libs or PIEs is always
disallowed the linker will already complain.  For others if you want to
ensure there will be no DT_TEXTREL PIEs or shared libs, either check them
afterwards (this is what e.g. glibc does), or add a ld option that will
error if it would create a DT_TEXTREL object.

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

> > 6. some changes to archs are generic PIC modifications (like changing the 
> > PIC support for arm and adding -pie). I do not have enough C knowledge 
> > to make this correcty, and it needs some more changes to be correct for 
> > all archs, sparc[64] needs a full rewrite of this part that I am not able 
> > to do.
> > My idea of this is to use flag_pic/builtin_define everywhere were possible 
> > (cc1 section: instead of -fPIC|-fpic|-fPIE|-fpie and asm section: using -K 
> > PIC or similar)

Yeah, using builtin_define etc. instead of the old style spec macros
is definitely desirable.  But I don't think this is something for 3.4
branch.

	Jakub


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