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

[Ralf Wildenhues]

[ subject adjusted a bit; and sorry for the long post ]

* Paul Jakma wrote on Tue, Nov 29, 2005 at 07:59:40AM CET:
> On Tue, 29 Nov 2005, Ralf Wildenhues wrote:
> 
> >As far as I can see it, libtool could support PIE reasonably well by
> >simply:
*snip*

Scratch the first suggestion.  I've been testing a bit.

> >Second possibility: the user could have created main.lo and linked that
> >directly into the program, although he shouldn't.  So let's fix above to
> >- ignoring completely -pie -fpie during compilation of the PIC object,
> > if any, but applying it to the non-PIC object, if any.
> >- ignoring both during linking of a library
> >- not ignoring both when linking a program
> 
> Right.

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.

> >Remaining questions:
> >- some projects employ assembler hackery that relies on, and creates
> > different code, depending upon -DPIC.  They'll probably have to
> > adjust, but in any case it may be nice for them to know.  Does -fpie
> > #define something they can use?

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

> >- How portable is this whole thing?  I mean, does PIE work on AIX, where
> > we do not even create non-PIC objects?
> 
> I think it needs runtime dynamic linker support, otherwise you can 
> not execute the resulting binary ;).

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.

Any other ones?  Does the Solaris linker support it, for example?
Do other linkers plan to support it?
Any compilers/linkers on which -pie/-fpie/-fPIE are spelled differently?
Is there an easy test we can use to find out whether it works?

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


> >Sure.  I believe my scheme outlined above, implemented in libtool, 
> >would simply solve all your problems.  Right?  What's missing?
> 
> I think it would, yes, just about - if you compile PIC at least.

So, let's summarize our current best bet: User does something like:
  configure LDFLAGS=-pie CFLAGS=-fpie CXXFLAGS=-fpie \
            FFLAGS=-fpie FCFLAGS=-fpie [...]
  make
  make install

when she already knows that PIE is supported.

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.

Probably there will be more fallout: third-party configure tests may
assume CFLAGS and LDFLAGS may also be used when creating shared objects
A temporary workaround for such breakage may be to try
  configure
  make LDFLAGS=-pie CFLAGS=-fpie [...]

instead.  But then, configure won't always be able to draw the correct
conclusions either.  So please report any such breakage you encounter,
so it can be fixed.

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.  Backporting to
ltmain.in of branch-1-5 is rather easy.  Also, it would be great if
someone could write nice documentation for this (hint, hint ;-).

OTOH, I probably won't want to apply the patch just yet.  I would like
to learn a bit more about possible pitfalls in this area.  What if the
compiler specs are changed to do PIE by default?  Can we regress there
in any way?  (I think not, but better be sure and test this.)
What if we later decide we want this whole PIE business integrated
tightly into libtool works (as we do PIC now)?

On GNU/Linux, x86_64, the test suite fares pretty good:
- the F77, FC, GCJ tests fail or skip, presumably(?) because g77-3.4.4,
  gfortran-4.0.0 and gcj-3.4.4 are not ready for either PIE or (I still
  need to check with a newer version).  
- `-static' is correctly detected as unsupported.
- You could even use `--disable-static', and it will do what you expect
  it to: use the libtool-created PIC objects everywhere, and the non-
  libtool-created PIE ones.  :)
- The test for pic_flag in libtool.m4 succeeds, but strictly speaking,
  it tests the wrong thing by not eliminating the -fpie in the resulting
  flags `-fpie -fpic'.  Oh well.

Cheers,
Ralf

        Basic support for PIE (position-independent executables).

        * libltdl/config/ltmain.m4sh (func_generate_dlsyms):
        Don't pass PIE flag for compilation of the symbol file object.
        (func_mode_compile): Pass PIE flag only for non-PIC objects.

Index: libltdl/config/ltmain.m4sh
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.21
diff -u -r1.21 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  25 Nov 2005 18:13:53 -0000      1.21
+++ libltdl/config/ltmain.m4sh  29 Nov 2005 19:25:30 -0000
@@ -968,9 +968,16 @@
          esac
          ;;
        esac
+       symtab_cflags=
+       for arg in $LTCFLAGS; do
+         case $arg in
+         -pie | -fpie | -fPIE) ;;
+         *) symtab_cflags="$symtab_cflags $arg" ;;
+         esac
+       done
 
        # Now compile the dynamic symbol file.
-       func_show_eval '(cd $output_objdir && $LTCC $LTCFLAGS 
-c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?'
+       func_show_eval '(cd $output_objdir && $LTCC$symtab_cflags 
-c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?'
 
        # Clean up the generated files.
        func_show_eval '$RM "$output_objdir/$my_dlsyms" "$nlist" "${nlist}S" 
"${nlist}T"'
@@ -1108,6 +1115,7 @@
     arg_mode=normal
     libobj=
     later=
+    pie_flag=
 
     for arg
     do
@@ -1134,6 +1142,11 @@
          continue
          ;;
 
+       -pie | -fpie | -fPIE)
+          pie_flag="$pie_flag $arg"
+         continue
+         ;;
+
        -shared | -static | -prefer-pic | -prefer-non-pic)
          later="$later $arg"
          continue
@@ -1423,7 +1436,7 @@
     if test "$build_old_libs" = yes; then
       if test "$pic_mode" != yes; then
        # Don't build PIC code
-       command="$base_compile $qsrcfile"
+       command="$base_compile $qsrcfile$pie_flag"
       else
        command="$base_compile $qsrcfile $pic_flag"
       fi