[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PIE support (was: 1.5.18: suppressing non-C language checks / pass f

From: Paul Jakma
Subject: Re: PIE support (was: 1.5.18: suppressing non-C language checks / pass flags to cc in link mode)
Date: Wed, 30 Nov 2005 18:10:30 +0000 (GMT)

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]