Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option

[Daniel Micay <danielmicay at gmail dot com>]

On 09/01/15 07:58 AM, Richard Biener wrote:
> 
> Looking at the actual implementation I wonder why it's not similar
> to how darwin gets at it default (not sure how it does).  Also
> looking at how DRIVER_SELF_SPECS is used I wonder if the
> functionality can be enabled with a simple
> 
> --with-specs="%{pie|fpic|fPIC|fpie|fPIE|fno-pic|fno-PIC|fno-pie|fno-PIE|shared|static|nostdlib|nodefaultlibs|nostartfiles:;:-fPIE
> -pie}"
> 
> at configure time (using CONFIGURE_SPECS).
> 
> I have no idea if the above is really the proper spec to use - why
> do you include static, nostdlib, nodefaultlibs and nostartfiles
> for example?  Similar, if I say

PIE isn't supported for static executables by binutils, etc. so it
does need to exclude that. The checks for nostdlib, nodefaultlibs
and nostartfiles do seem unnecessary. I think distributions include
those in the existing wrapper scripts and GCC patches because it
avoids the need for patching build systems for kernel / freestanding
code to include -fno-pie, but it's more correct to leave these out.
 
>  gcc -pie -c t.c
> 
> we will end up with a non-PIE object, and linking with -fPIE will
> end up with a DYN_EXEC object.
> 
> I believe you want to treat link and compile arguments separately
> (and adjust the link spec for linking).  I also would have said that
> elfos.h is more appropriate than gnu-user.h, but ...

Handling it separately is what the existing wrapper scripts for this do:

    -fno-PIC|-fno-pic|-fno-PIE|-fno-pie|-static|--static|-shared|--shared)
      force_fPIE=0
      force_pie=0
      ;;
    -fPIC|-fpic|-fPIE|-fpie)
      force_fPIE=0
      ;;
    -c|-E|-S)
      force_pie=0
      ;;

I think it's appropriate for it to 
 
> That said, the patch looks more like a hack (and see above how
> to achieve the same without a patch(?)), not like a proper implementation
> of a PIE default.

I don't think it can be considered a hack if it's handling all of the cases
correctly, so it might need some changes from the current implementation but
that doesn't make it a dead end. Is it actually done in a significantly
different way for OS X?

If it can be done by passing --with-specs to configure then that could be a
viable alternative for distributions that do not want to add GCC patches or
use wrapper scripts (Arch Linux) but I'm not sure that it will fly.

Attachment: signature.asc
Description: OpenPGP digital signature