Re: PIE support (was: 1.5.18: suppressing non-C language checks / pass flags to cc in link mode)

[Paul Jakma]

On Tue, 29 Nov 2005, Ralf Wildenhues wrote:

> This seems to me the superior solution.  Thus, let's kill the 
> --with-pic idea, too.  It won't get us over main.o 
> compiled-without-libtool and neither one of -fpic or -fpie in 
> CFLAGS anyway.  And I can't see why it should be more useful to 
> have two PIC objects rather than one PIC and one PIE object.

I don't know, but PIE and PIC don't compile to same thing AFAICT. I 
don't know the significance of that though.

> AFAIK there isn't.  gcc defines __PIC__, __pic__.  Thus one open 
> question would be whether we should notify the compiler/assembler 
> that PIE code is created.  We could `-DPIC -DPIE', for example (PIC 
> because most assembler code will likely work unmodified from the
> PIC version,

Depends on the constraints I guess. Most sane asm will be inline and
operating on indirect memory references in parameters setup by GCC,
those would be relocatable. But anything is possible with asm ;).

> see http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00145.html ). Or, 
> to not avoid further namespace invasion, maybe `-DPIC -DLT_PIE'. 
> For CC and CXX tags?  Suggestions?  Maybe only add -DPIC?
>
> One weak reason against adding anything would be the fact that
> non-libtool created PIE objects would not see the define either.  :-/
> (Actually, that could be interpreted as reason for the program author
> to rely on __PIC__ or __pic__ iff this is gcc-specific code anyway.)

Why not leave the define to GCC? You pointed out gcc sets defines for 
PIC. That would work for the non-libtool-compiled object case too.

Ie any problems arise here will be due to missing functionality in 
GCC, and likely remedied there in due course as PIE becomes more 
commonly used.

> Well.  It's implemented in GNU binutils ld as of recently enough, 
> GCC as of recently enough, and with them is said to work on all ELF 
> systems.

Interesting to know. I just tried with GCC 3.4.3 as supplied with 
SNV_09 and, while it accepted -fpie -pie on the commandline, the 
resulting executable was not reported as relocatable by 'file'.

> Any other ones?  Does the Solaris linker support it, for example?

Not at the moment no.

> My tests with gcc-3.4.4 show that -fpie/-fPIE always override 
> -fpic/-fPIC, independent of the order in which they were passed. 
> (What an unfortunate choice, by the way.  Oh well.)

Indeed. I think that has been discussed on the gcc lists.

> Libtool then does this (implemented in patch below):
> - strip -pie/-fpie/-fPIE from compile flags for PIC objects
>  and from LTCFLAGS for compilation of the symfile object as that one
>  should be PIC (I believe stripping from LTCC is not needed: putting
>  `-pie' in CC will break creating shared libraries; don't do that).
> - strip -pie/-fpie/-fPIE from link flags for libraries, but
>  not for programs: actually, this needs no changes; libtool already
>  does exactly the right thing here.

Yep that could work.

> I'd be glad if someone could test CVS HEAD with the patch below on a
> bunch of packages, and/or with the Libtool test suite.

I'll give a try soon.

> On GNU/Linux, x86_64, the test suite fares pretty good:

Nice :)

> Cheers,
> Ralf


regards,
--
Paul Jakma      address@hidden  address@hidden  Key ID: 64A2FF6A
Fortune:
Common sense is the collection of prejudices acquired by age eighteen.
                -- Albert Einstein