Don't use PLT nor GOT in libc.a [BZ #20750]

  There is no need to use PLT nor GOT in libc.a to branch to a function,
regardless whether libc.a is compiled with PIC or not.

Tested on x86-64.  OK for master?

H.J.
---
	[BZ #20750]
	* sysdeps/x86_64/sysdep.h (JUMPTARGET): Check SHARED instead
	of PIC.
---
 sysdeps/x86_64/sysdep.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
  

On 11/04/2016 06:47 PM, H.J. Lu wrote:
> There is no need to use PLT nor GOT in libc.a to branch to a function,
> regardless whether libc.a is compiled with PIC or not.
>
> Tested on x86-64.  OK for master?

Isn't this header file used outside of libc as well?

(And the commit message should mention that this change is specific to 
x86_64.)

Thanks,
Florian
  

On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/04/2016 06:47 PM, H.J. Lu wrote:
>>
>> There is no need to use PLT nor GOT in libc.a to branch to a function,
>> regardless whether libc.a is compiled with PIC or not.
>>
>> Tested on x86-64.  OK for master?
>
>
> Isn't this header file used outside of libc as well?

It is used for other .a files.  If they aren't used to create static binaries,
PLT/GOT may be used.  The resulting executable will work correctly.

> (And the commit message should mention that this change is specific to
> x86_64.)
>

I will update it.
  

On 11/04/2016 08:25 PM, H.J. Lu wrote:
> On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 11/04/2016 06:47 PM, H.J. Lu wrote:
>>>
>>> There is no need to use PLT nor GOT in libc.a to branch to a function,
>>> regardless whether libc.a is compiled with PIC or not.
>>>
>>> Tested on x86-64.  OK for master?
>>
>>
>> Isn't this header file used outside of libc as well?
>
> It is used for other .a files.  If they aren't used to create static binaries,
> PLT/GOT may be used.  The resulting executable will work correctly.

You mean because “name” is automatically mapped to “name@plt”?

I find this comment not very illuminating:

+/* For libc.a, we want to branch to target directly.  */
  # define JUMPTARGET(name)	name

And cheating the static linker in this way seems like a future 
maintenance hazard.

Thanks,
Florian
  

On Mon, Nov 7, 2016 at 8:03 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/04/2016 08:25 PM, H.J. Lu wrote:
>>
>> On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 11/04/2016 06:47 PM, H.J. Lu wrote:
>>>>
>>>>
>>>> There is no need to use PLT nor GOT in libc.a to branch to a function,
>>>> regardless whether libc.a is compiled with PIC or not.
>>>>
>>>> Tested on x86-64.  OK for master?
>>>
>>>
>>>
>>> Isn't this header file used outside of libc as well?
>>
>>
>> It is used for other .a files.  If they aren't used to create static
>> binaries,
>> PLT/GOT may be used.  The resulting executable will work correctly.
>
>
> You mean because “name” is automatically mapped to “name@plt”?

No.  There is no "@plt".  Linker will create a PLT entry if the function
is defined in a shared object.

> I find this comment not very illuminating:
>
> +/* For libc.a, we want to branch to target directly.  */
>  # define JUMPTARGET(name)      name
>
> And cheating the static linker in this way seems like a future maintenance
> hazard.
>

It is ok as long as those static archives aren't used to create shared
objects.
  

Ping.  My distribution wants to enable PIE and -z,now by default and
this is required for glibc to build.

Allan

On 08/11/16 03:13, H.J. Lu wrote:
> On Mon, Nov 7, 2016 at 8:03 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 11/04/2016 08:25 PM, H.J. Lu wrote:
>>>
>>> On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com>
>>> wrote:
>>>>
>>>> On 11/04/2016 06:47 PM, H.J. Lu wrote:
>>>>>
>>>>>
>>>>> There is no need to use PLT nor GOT in libc.a to branch to a function,
>>>>> regardless whether libc.a is compiled with PIC or not.
>>>>>
>>>>> Tested on x86-64.  OK for master?
>>>>
>>>>
>>>>
>>>> Isn't this header file used outside of libc as well?
>>>
>>>
>>> It is used for other .a files.  If they aren't used to create static
>>> binaries,
>>> PLT/GOT may be used.  The resulting executable will work correctly.
>>
>>
>> You mean because “name” is automatically mapped to “name@plt”?
> 
> No.  There is no "@plt".  Linker will create a PLT entry if the function
> is defined in a shared object.
> 
>> I find this comment not very illuminating:
>>
>> +/* For libc.a, we want to branch to target directly.  */
>>  # define JUMPTARGET(name)      name
>>
>> And cheating the static linker in this way seems like a future maintenance
>> hazard.
>>
> 
> It is ok as long as those static archives aren't used to create shared
> objects.
>
  

On 11/24/2016 12:58 PM, Allan McRae wrote:
> Ping.  My distribution wants to enable PIE and -z,now by default and
> this is required for glibc to build.

My question has been answered.  H.J., could you please check this in?

Thanks,
Florian
  

On 24/11/16 11:58, Allan McRae wrote:
> Ping.  My distribution wants to enable PIE and -z,now by default and
> this is required for glibc to build.
> 

how does this help?

i think glibc has no static pie entry point that can
resolve relative relocs of pie code..

(i think only musl libc supports this now, used in
the alpine linux distro, which have some toolchain
patches to make it work).