| Message ID | 20150113125201.GA18558@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 01/13/15 05:52, H.J. Lu wrote: > 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? > > That is a good question. We can compile gcrt1.o with -fPIC and it will > work with both -pg and -pg -pie. I will open a glibc bug. Thanks for getting the bug opened, there's a reasonable chance that we'll have the gcrt1.o we want in the not too distant future. > > Here is the updated patch without the check_profiling_available change. > OK for trunk? > > Thanks. > > H.J. > --- > Subject: [PATCH 1/5] Add check_effective_target_pie > > Hi, > > This patch adds check_effective_target_pie to check if the current > multilib generates PIE by default. > > 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_effective_target_pie): New. OK. Jeff
Jeff Law <law@redhat.com> writes: >> Subject: [PATCH 1/5] Add check_effective_target_pie >> >> Hi, >> >> This patch adds check_effective_target_pie to check if the current >> multilib generates PIE by default. >> >> 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_effective_target_pie): New. > OK. The new proc is bogus, unfortunately: there's already an existing check_effective_target_pie that checks if a target can support PIE. The new one just overrides the previous one. On targets supporting PIE (like Darwin), but not defaulting to it, the PIE tests suddenly turn out UNSUPPORTED. You should rename the new one to e.g. check_effective_target_pie_default, update the single user, and document it in sourcebuild.texi. Rainer
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..0ac9646 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -1080,6 +1080,16 @@ proc check_effective_target_nonpic { } { }] } +# Return 1 if the current multilib generates 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 { } {