diff mbox

[testsuite] PATCH: Add check_effective_target_pie

Message ID 20150111235837.GA26961@gmail.com
State New
Headers show

Commit Message

H.J. Lu Jan. 11, 2015, 11:58 p.m. UTC 
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

Comments

Jeff Law Jan. 12, 2015, 6:09 p.m. UTC | #1 
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.

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

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

jeff
H.J. Lu Jan. 12, 2015, 7:29 p.m. UTC | #2 
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.
Jeff Law Jan. 12, 2015, 7:46 p.m. UTC | #3 
On 01/12/15 12:29, H.J. Lu wrote:

>> 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.
Can you please investigate the questions.  Showing me the link failure 
doesn't really help much here.  It tells me there's no crt1.o, but it 
says nothing about *why*.

Is there inherently something about PIE/pg that makes them impossible to 
work together or is this an implementation detail?  If the latter, then 
is the implementation detail a target issue or not.

Jeff
H.J. Lu Jan. 12, 2015, 8:11 p.m. UTC | #4 
On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> On 01/12/15 12:59, H.J. Lu wrote:
>>
>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>> the choices of crt1.o are
>>
>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>
>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>> Linux without changing glibc.
>
> You're totally missing the point.  What I care about is *why*.
>
> Showing me spec file fragments is totally unhelpful.  What is the technical
> reason why pg and pie are mutually exclusive?

What kind of "technical" reason are you looking for?  glibc doesn't
provide the right crt1 file for GCC to support this combination.  You
can't define GNU_USER_TARGET_STARTFILE_SPEC to support
-pg and -pie.

If you are asking "why" glibc doesn't provide one, my guess is no
one has requested one before.
Magnus Granberg Jan. 12, 2015, 9:51 p.m. UTC | #5 
måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> > On 01/12/15 12:59, H.J. Lu wrote:
> >> I don't know if -pg will work PIE on any targets.  For Linux/x86
> >> the choices of crt1.o are
> >> 
> >> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> >> 
> >> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
> >> only crt1 files provided by glibc.  You can't even try -pg -pie on
> >> Linux without changing glibc.
> > 
> > You're totally missing the point.  What I care about is *why*.
> > 
With -pg it use gcrt1.o object file and that file is not compile with -fPIC. 
When you build a shared lib on x86_64 all the objects files need to be buiit 
with -fPIC else you get a error like that one abow and it is the same problems 
when you build bin with -fPIE and linke with -pie.
Glibc do not provide one that is compile with -fPIC

> > Showing me spec file fragments is totally unhelpful.  What is the
> > technical
> > reason why pg and pie are mutually exclusive?
> 
> What kind of "technical" reason are you looking for?  glibc doesn't
> provide the right crt1 file for GCC to support this combination.  You
> can't define GNU_USER_TARGET_STARTFILE_SPEC to support
> -pg and -pie.
> 
> If you are asking "why" glibc doesn't provide one, my guess is no
> one has requested one before.
Jeff Law Jan. 12, 2015, 10:04 p.m. UTC | #6 
On 01/12/15 14:51, Magnus Granberg wrote:
> måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
>> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
>>> On 01/12/15 12:59, H.J. Lu wrote:
>>>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>>>> the choices of crt1.o are
>>>>
>>>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>>>
>>>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>>>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>>>> Linux without changing glibc.
>>>
>>> You're totally missing the point.  What I care about is *why*.
>>>
> With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> When you build a shared lib on x86_64 all the objects files need to be buiit
> with -fPIC else you get a error like that one abow and it is the same problems
> when you build bin with -fPIE and linke with -pie.
> Glibc do not provide one that is compile with -fPIC
Is there some reason why glibc could not provide gcrt1.o compiled with 
-fPIC?


Jeff
H.J. Lu Jan. 13, 2015, 2:31 p.m. UTC | #7 
On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
> On 01/12/15 14:51, Magnus Granberg wrote:
> >måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> >>On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> >>>On 01/12/15 12:59, H.J. Lu wrote:
> >>>>I don't know if -pg will work PIE on any targets.  For Linux/x86
> >>>>the choices of crt1.o are
> >>>>
> >>>>%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> >>>>
> >>>>-shared, -pg and -pie are mutually exclusive. Those crt1 files are
> >>>>only crt1 files provided by glibc.  You can't even try -pg -pie on
> >>>>Linux without changing glibc.
> >>>
> >>>You're totally missing the point.  What I care about is *why*.
> >>>
> >With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> >When you build a shared lib on x86_64 all the objects files need to be buiit
> >with -fPIC else you get a error like that one abow and it is the same problems
> >when you build bin with -fPIE and linke with -pie.
> >Glibc do not provide one that is compile with -fPIC
> Is there some reason why glibc could not provide gcrt1.o compiled with
> -fPIC?
> 

I opened a glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=17836

and submitted a patch:

https://sourceware.org/ml/libc-alpha/2015-01/msg00284.html

H.J.
diff mbox

Patch

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
+    }
+
     # Support for -p on solaris2 relies on mcrt1.o which comes with the
     # vendor compiler.  We cannot reliably predict the directory where the
     # vendor compiler (and thus mcrt1.o) is installed so we can't
@@ -1080,6 +1085,16 @@  proc check_effective_target_nonpic { } {
     }]
 }
 
+# Return 1 if the current multilib generatse PIE by default.
+
+proc check_effective_target_pie { } {
+    return [check_no_compiler_messages pie assembly {
+	#ifndef __PIE__
+	#error unsupported
+	#endif
+    }]
+}
+
 # Return 1 if the target does not use a status wrapper.
 
 proc check_effective_target_unwrapped { } {