This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Remove debug/stack_chk_fail_local.c [BZ #21740]


On Tue, Jul 18, 2017 at 10:11 AM, Nick Alcock <nix@esperi.org.uk> wrote:
> On 18 Jul 2017, H. J. Lu uttered the following:
>> From 47d95763a35fbc83ac871b10fc59f9eca1ef0a40 Mon Sep 17 00:00:00 2001
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>> Date: Sun, 9 Jul 2017 08:39:17 -0700
>> Subject: [PATCH] Don't add stack_chk_fail_local.o to libc.a [BZ #21740]
>>
>> commit 524a8ef2ad76af8ac049293d993a1856b0d888fb
>> Author: Nick Alcock <nick.alcock@oracle.com>
>> Date:   Mon Dec 26 10:08:57 2016 +0100
>>
>>     PLT avoidance for __stack_chk_fail [BZ #7065]
>>
>>     Add a hidden __stack_chk_fail_local alias to libc.so,
>>     and make sure that on targets which use __stack_chk_fail,
>>     this does not introduce a local PLT reference into libc.so.
>>
>> which unconditionally added
>>
>> strong_alias (__stack_chk_fail, __stack_chk_fail_local)
>>
>> defines __stack_chk_fail_local as an alias of __stack_chk_fail in libc.a.
>> There is no need to add stack_chk_fail_local.o to libc.a.  We only need
>> to add stack_chk_fail_local.oS to libc_nonshared.a.
>
> Completely agreed -- we only need the _local alias because of internal
> calls within the *shared* libc and related objects (in all of which the
> symbol is hidden). The nonshared libc just calls __stack_chk_fail
> directly and should not reference stack_chk_fail_local at all, and
> nothing else should have undefined references to it because the only
> objects that presently reference it should also contain a definition of
> it.

I am checking it in.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]