Re: [testsuite] PATCH: Add check_effective_target_pie

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 12, 2015 at 10:09 AM, Jeff Law <law@redhat.com> wrote:
> On 01/11/15 16:58, H.J. Lu wrote:
>>
>> Hi,
>>
>> This patch adds check_effective_target_pie to check if the current
>> multilib generatse PIE by default.  I will submit other patches to use
>> it.  OK for trunk?
>>
>> Thanks.
>>
>> H.J.
>> ---
>> 2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>
>>
>>         * gcc.target/i386/pie.c: New test.
>>
>>         * lib/target-supports.exp (check_profiling_available): Return 0
>>         if PIE is enabled.
>>         (check_effective_target_pie): New.
>> ---
>>   gcc/testsuite/gcc.target/i386/pie.c   | 12 ++++++++++++
>>   gcc/testsuite/lib/target-supports.exp | 15 +++++++++++++++
>>   2 files changed, 27 insertions(+)
>>   create mode 100644 gcc/testsuite/gcc.target/i386/pie.c
>>
>> diff --git a/gcc/testsuite/gcc.target/i386/pie.c
>> b/gcc/testsuite/gcc.target/i386/pie.c
>> new file mode 100644
>> index 0000000..0a9f5ee
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/pie.c
>> @@ -0,0 +1,12 @@
>> +/* { dg-do compile { target pie } } */
>> +/* { dg-options "-O2" } */
>> +
>> +int foo (void);
>> +
>> +int
>> +main (void)
>> +{
>> +  return foo ();
>> +}
>> +
>> +/* { dg-final { scan-assembler "foo@PLT" } } */
>> diff --git a/gcc/testsuite/lib/target-supports.exp
>> b/gcc/testsuite/lib/target-supports.exp
>> index f5c6db8..549bcdf 100644
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -475,6 +475,11 @@ proc check_profiling_available { test_what } {
>>         }
>>       }
>>
>> +    # Profiling don't work with -fPIE -pie.
>> +    if { [check_effective_target_pie] } {
>> +      return 0
>> +    }
>
> Is this an inherent restriction of -fPIE, or is it merely an implementation
> detail?  If the latter, is that implementation detail a target issue?  ie,
> could we have a target that supports profiling in conjunction with -fPIE?
> If so, then this test seems too restrictive.

[hjl@gnu-6 tmp]$ gcc -pie -fPIE -pg h.c
/usr/local/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/gcrt1.o:
relocation R_X86_64_32S against `__libc_csu_fini' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/gcrt1.o:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status
[hjl@gnu-6 tmp]$

There is no crt1.o from glibc to support -pg -pie -fPIE.
I don't know if other targets support -pie -fPIE.

>>   }
>>
>> +# Return 1 if the current multilib generatse PIE by default.
>
> s/generatse/generates/

I will fix it.

> Waiting on answer to PIE vs pg question above prior to approving or
> requesting further refinement.

Sure.

-- 
H.J.