diff mbox

S390: Support PLT and GOT references in check-localplt.

Message ID fbddd3a3-9d00-8b56-e5ed-c360ccbe28ae@linux.vnet.ibm.com
State Committed
Headers

Commit Message

Stefan Liebler Aug. 9, 2016, 1:34 p.m. UTC 
  Hi,

on s390x the test elf/check-localplt is failing after recent commits:
"elf: Do not use memalign for TCB/TLS blocks allocation [BZ #17730]"
"elf: Avoid using memalign for TLS allocations [BZ #17730]"
"elf: dl-minimal malloc needs to respect fundamental alignment"
due to "Missing required PLT reference: ld.so: __libc_memalign".

After the commits __libc_memalign is only called in elf/dl-minimal.c in 
malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT 
instead of R_390_JMP_SLOT. __libc_memalign is called via 
function-pointer loaded from GOT instead of calling via a plt-stub. In 
this case there is the R_390_GLOB_DAT relocation in section .rela.dyn 
instead of R_390_JMP_SLOT in .rela.plt.
This patch marks ld.so: __libc_memalign with R_390_GLOB_DAT in 
localplt.data to allow both relocations.
If build with -fno-optimize-sibling-calls or on s390(31bit) a 
R_390_JMP_SLOT is generated.

Okay to commit?

Bye
Stefan

ChangeLog:

	* sysdeps/unix/sysv/linux/s390/localplt.data: Mark
	ld.so: __libc_memalign with "+ RELA R_390_GLOB_DAT".

Comments

Florian Weimer Aug. 9, 2016, 1:53 p.m. UTC | #1 
On 08/09/2016 03:34 PM, Stefan Liebler wrote:
> After the commits __libc_memalign is only called in elf/dl-minimal.c in
> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
> instead of R_390_JMP_SLOT. __libc_memalign is called via
> function-pointer loaded from GOT instead of calling via a plt-stub.

Huh.  I wonder if this is intended.  Surely the malloc implementation in 
elf/dl-minimal.c should always call the __libc_memalign implementation 
in the same file?

Thanks,
Florian
Stefan Liebler Aug. 9, 2016, 2:22 p.m. UTC | #2 
On 08/09/2016 03:53 PM, Florian Weimer wrote:
> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>> After the commits __libc_memalign is only called in elf/dl-minimal.c in
>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>> function-pointer loaded from GOT instead of calling via a plt-stub.
>
> Huh.  I wonder if this is intended.  Surely the malloc implementation in
> elf/dl-minimal.c should always call the __libc_memalign implementation
> in the same file?
>
> Thanks,
> Florian
>

Please have a look at the other localplt.data files, e.g. 
sysdeps/x86_64/localplt.data:
# The dynamic loader uses __libc_memalign internally to allocate aligned
# TLS storage. The other malloc family of functions are expected to allow
# user symbol interposition.
ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT

All contains the __libc_memalign relocation.
On s390x it has also existed before but a plt-stub was used. If you now 
use the compiler flag -fno-optimize-sibling-calls you'll get the 
plt-stub as before. With this optimization the relocation is done via a 
function pointer.

Bye
Stefan
Stefan Liebler Aug. 17, 2016, 8:22 a.m. UTC | #3 
On 08/09/2016 03:34 PM, Stefan Liebler wrote:
> Hi,
>
> on s390x the test elf/check-localplt is failing after recent commits:
> "elf: Do not use memalign for TCB/TLS blocks allocation [BZ #17730]"
> "elf: Avoid using memalign for TLS allocations [BZ #17730]"
> "elf: dl-minimal malloc needs to respect fundamental alignment"
> due to "Missing required PLT reference: ld.so: __libc_memalign".
>
> After the commits __libc_memalign is only called in elf/dl-minimal.c in
> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
> instead of R_390_JMP_SLOT. __libc_memalign is called via
> function-pointer loaded from GOT instead of calling via a plt-stub. In
> this case there is the R_390_GLOB_DAT relocation in section .rela.dyn
> instead of R_390_JMP_SLOT in .rela.plt.
> This patch marks ld.so: __libc_memalign with R_390_GLOB_DAT in
> localplt.data to allow both relocations.
> If build with -fno-optimize-sibling-calls or on s390(31bit) a
> R_390_JMP_SLOT is generated.
>
> Okay to commit?
>
> Bye
> Stefan
>
> ChangeLog:
>
>     * sysdeps/unix/sysv/linux/s390/localplt.data: Mark
>     ld.so: __libc_memalign with "+ RELA R_390_GLOB_DAT".
Are there any objections?
Otherwise I'll commit this patch tomorrow.

Bye
Stefan
Florian Weimer Aug. 17, 2016, 1:48 p.m. UTC | #4 
On 08/09/2016 04:22 PM, Stefan Liebler wrote:
> On 08/09/2016 03:53 PM, Florian Weimer wrote:
>> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>>> After the commits __libc_memalign is only called in elf/dl-minimal.c in
>>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>>> function-pointer loaded from GOT instead of calling via a plt-stub.
>>
>> Huh.  I wonder if this is intended.  Surely the malloc implementation in
>> elf/dl-minimal.c should always call the __libc_memalign implementation
>> in the same file?
>>
>> Thanks,
>> Florian
>>
>
> Please have a look at the other localplt.data files, e.g.
> sysdeps/x86_64/localplt.data:
> # The dynamic loader uses __libc_memalign internally to allocate aligned
> # TLS storage. The other malloc family of functions are expected to allow
> # user symbol interposition.
> ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT
>
> All contains the __libc_memalign relocation.
> On s390x it has also existed before but a plt-stub was used. If you now
> use the compiler flag -fno-optimize-sibling-calls you'll get the
> plt-stub as before. With this optimization the relocation is done via a
> function pointer.

Okay, but shouldn't be __libc_memalign in dl-minimal.c declared as 
attribute_hidden?

Thanks,
Florian
Stefan Liebler Aug. 18, 2016, 10:42 a.m. UTC | #5 
On 08/17/2016 03:48 PM, Florian Weimer wrote:
> On 08/09/2016 04:22 PM, Stefan Liebler wrote:
>> On 08/09/2016 03:53 PM, Florian Weimer wrote:
>>> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>>>> After the commits __libc_memalign is only called in elf/dl-minimal.c in
>>>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>>>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>>>> function-pointer loaded from GOT instead of calling via a plt-stub.
>>>
>>> Huh.  I wonder if this is intended.  Surely the malloc implementation in
>>> elf/dl-minimal.c should always call the __libc_memalign implementation
>>> in the same file?
>>>
>>> Thanks,
>>> Florian
>>>
>>
>> Please have a look at the other localplt.data files, e.g.
>> sysdeps/x86_64/localplt.data:
>> # The dynamic loader uses __libc_memalign internally to allocate aligned
>> # TLS storage. The other malloc family of functions are expected to allow
>> # user symbol interposition.
>> ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT
>>
>> All contains the __libc_memalign relocation.
>> On s390x it has also existed before but a plt-stub was used. If you now
>> use the compiler flag -fno-optimize-sibling-calls you'll get the
>> plt-stub as before. With this optimization the relocation is done via a
>> function pointer.
>
> Okay, but shouldn't be __libc_memalign in dl-minimal.c declared as
> attribute_hidden?
>
> Thanks,
> Florian
>
I don't know. Can you simply do this as __libc_memalign is also 
mentioned in elf/Versions file?
ld {
   GLIBC_2.0 {
     # Function from libc.so which must be shared with libc.
     __libc_memalign; calloc; free; malloc; realloc;

     _r_debug;
   }
Stefan Liebler Aug. 23, 2016, 11:28 a.m. UTC | #6 
On 08/18/2016 12:42 PM, Stefan Liebler wrote:
> On 08/17/2016 03:48 PM, Florian Weimer wrote:
>> On 08/09/2016 04:22 PM, Stefan Liebler wrote:
>>> On 08/09/2016 03:53 PM, Florian Weimer wrote:
>>>> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>>>>> After the commits __libc_memalign is only called in
>>>>> elf/dl-minimal.c in
>>>>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>>>>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>>>>> function-pointer loaded from GOT instead of calling via a plt-stub.
>>>>
>>>> Huh.  I wonder if this is intended.  Surely the malloc
>>>> implementation in
>>>> elf/dl-minimal.c should always call the __libc_memalign implementation
>>>> in the same file?
>>>>
>>>> Thanks,
>>>> Florian
>>>>
>>>
>>> Please have a look at the other localplt.data files, e.g.
>>> sysdeps/x86_64/localplt.data:
>>> # The dynamic loader uses __libc_memalign internally to allocate aligned
>>> # TLS storage. The other malloc family of functions are expected to
>>> allow
>>> # user symbol interposition.
>>> ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT
>>>
>>> All contains the __libc_memalign relocation.
>>> On s390x it has also existed before but a plt-stub was used. If you now
>>> use the compiler flag -fno-optimize-sibling-calls you'll get the
>>> plt-stub as before. With this optimization the relocation is done via a
>>> function pointer.
>>
>> Okay, but shouldn't be __libc_memalign in dl-minimal.c declared as
>> attribute_hidden?
>>
>> Thanks,
>> Florian
>>
> I don't know. Can you simply do this as __libc_memalign is also
> mentioned in elf/Versions file?
> ld {
>   GLIBC_2.0 {
>     # Function from libc.so which must be shared with libc.
>     __libc_memalign; calloc; free; malloc; realloc;
>
>     _r_debug;
>   }
>

Is there any news about __libc_memalign?
Otherwise I'd like to commit this patch.
I think if you change something about __libc_memalign you have to touch 
the other architectures as well.

Bye
Stefan
Florian Weimer Aug. 26, 2016, 11:49 a.m. UTC | #7 
On 08/23/2016 01:28 PM, Stefan Liebler wrote:
> On 08/18/2016 12:42 PM, Stefan Liebler wrote:
>> On 08/17/2016 03:48 PM, Florian Weimer wrote:
>>> On 08/09/2016 04:22 PM, Stefan Liebler wrote:
>>>> On 08/09/2016 03:53 PM, Florian Weimer wrote:
>>>>> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>>>>>> After the commits __libc_memalign is only called in
>>>>>> elf/dl-minimal.c in
>>>>>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>>>>>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>>>>>> function-pointer loaded from GOT instead of calling via a plt-stub.
>>>>>
>>>>> Huh.  I wonder if this is intended.  Surely the malloc
>>>>> implementation in
>>>>> elf/dl-minimal.c should always call the __libc_memalign implementation
>>>>> in the same file?
>>>>>
>>>>> Thanks,
>>>>> Florian
>>>>>
>>>>
>>>> Please have a look at the other localplt.data files, e.g.
>>>> sysdeps/x86_64/localplt.data:
>>>> # The dynamic loader uses __libc_memalign internally to allocate
>>>> aligned
>>>> # TLS storage. The other malloc family of functions are expected to
>>>> allow
>>>> # user symbol interposition.
>>>> ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT
>>>>
>>>> All contains the __libc_memalign relocation.
>>>> On s390x it has also existed before but a plt-stub was used. If you now
>>>> use the compiler flag -fno-optimize-sibling-calls you'll get the
>>>> plt-stub as before. With this optimization the relocation is done via a
>>>> function pointer.
>>>
>>> Okay, but shouldn't be __libc_memalign in dl-minimal.c declared as
>>> attribute_hidden?
>>>
>>> Thanks,
>>> Florian
>>>
>> I don't know. Can you simply do this as __libc_memalign is also
>> mentioned in elf/Versions file?
>> ld {
>>   GLIBC_2.0 {
>>     # Function from libc.so which must be shared with libc.
>>     __libc_memalign; calloc; free; malloc; realloc;
>>
>>     _r_debug;
>>   }
>>
>
> Is there any news about __libc_memalign?
> Otherwise I'd like to commit this patch.
> I think if you change something about __libc_memalign you have to touch
> the other architectures as well.

Sorry, I don't feel qualified to comment on this.

What has changes is that we no longer reference __libc_memalign, in 
order to simplify the interposition of a custom malloc.

I find all this rather puzzling because we really do not want to 
interpose the dl-minimal.c malloc for the whole process, and yet the 
elf/Versions file lists it …

Florian
Stefan Liebler Aug. 30, 2016, 3:52 p.m. UTC | #8 
On 08/26/2016 01:49 PM, Florian Weimer wrote:
> On 08/23/2016 01:28 PM, Stefan Liebler wrote:
>> On 08/18/2016 12:42 PM, Stefan Liebler wrote:
>>> On 08/17/2016 03:48 PM, Florian Weimer wrote:
>>>> On 08/09/2016 04:22 PM, Stefan Liebler wrote:
>>>>> On 08/09/2016 03:53 PM, Florian Weimer wrote:
>>>>>> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>>>>>>> After the commits __libc_memalign is only called in
>>>>>>> elf/dl-minimal.c in
>>>>>>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>>>>>>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>>>>>>> function-pointer loaded from GOT instead of calling via a plt-stub.
>>>>>>
>>>>>> Huh.  I wonder if this is intended.  Surely the malloc
>>>>>> implementation in
>>>>>> elf/dl-minimal.c should always call the __libc_memalign
>>>>>> implementation
>>>>>> in the same file?
>>>>>>
>>>>>> Thanks,
>>>>>> Florian
>>>>>>
>>>>>
>>>>> Please have a look at the other localplt.data files, e.g.
>>>>> sysdeps/x86_64/localplt.data:
>>>>> # The dynamic loader uses __libc_memalign internally to allocate
>>>>> aligned
>>>>> # TLS storage. The other malloc family of functions are expected to
>>>>> allow
>>>>> # user symbol interposition.
>>>>> ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT
>>>>>
>>>>> All contains the __libc_memalign relocation.
>>>>> On s390x it has also existed before but a plt-stub was used. If you
>>>>> now
>>>>> use the compiler flag -fno-optimize-sibling-calls you'll get the
>>>>> plt-stub as before. With this optimization the relocation is done
>>>>> via a
>>>>> function pointer.
>>>>
>>>> Okay, but shouldn't be __libc_memalign in dl-minimal.c declared as
>>>> attribute_hidden?
>>>>
>>>> Thanks,
>>>> Florian
>>>>
>>> I don't know. Can you simply do this as __libc_memalign is also
>>> mentioned in elf/Versions file?
>>> ld {
>>>   GLIBC_2.0 {
>>>     # Function from libc.so which must be shared with libc.
>>>     __libc_memalign; calloc; free; malloc; realloc;
>>>
>>>     _r_debug;
>>>   }
>>>
>>
>> Is there any news about __libc_memalign?
>> Otherwise I'd like to commit this patch.
>> I think if you change something about __libc_memalign you have to touch
>> the other architectures as well.
>
> Sorry, I don't feel qualified to comment on this.
>
> What has changes is that we no longer reference __libc_memalign, in
> order to simplify the interposition of a custom malloc.
Yes. Your patches removed the usage of __libc_memalign and instead used 
malloc in elf/dl-minimal.c which is the last place where __libc_memalign 
is called:
void * weak_function
malloc (size_t n)
{
   return __libc_memalign (MALLOC_ALIGNMENT, n);
}

Here is the relocation on intel, too:
objdump -dr elf/dl-minimal.os
0000000000000110 <malloc>:
  110:   48 89 fe                mov    %rdi,%rsi
  113:   bf 10 00 00 00          mov    $0x10,%edi
  118:   e9 00 00 00 00          jmpq   11d <malloc+0xd>
                         119: R_X86_64_PLT32     __libc_memalign-0x4
  11d:   0f 1f 00                nopl   (%rax)

I had a further look at the __libc_memalign relocations used in ld.so ..

... before your patches:
Relocation section '.rela.dyn'
000000026058  000d0000000a R_390_GLOB_DAT    000000000001b3b8 
__libc_memalign + 0
(used in elf/dl-minimal.os in malloc function via function pointer in got)

Relocation section '.rela.plt':
000000026018  000d0000000b R_390_JMP_SLOT    000000000001b3b8 
__libc_memalign + 0
(used via plt-stub in tls_get_addr_tail, _dl_allocate_tls_storage, 
_dl_allocate_tls in elf/dl-tls.os)


... after your patches:
Relocation section '.rela.dyn':
000000026050  000d0000000a R_390_GLOB_DAT    000000000001b298 
__libc_memalign + 0
(used in elf/dl-minimal.os in malloc function via function pointer in got)

=> As the __libc_memalign usages in elf/dl-tls.os are removed,
there is no call of __libc_memalign via plt-stub anymore, thus the 
testcase elf/check-localplt is failing. My patch is allowing the 
R_390_GLOB_DAT relocation as well. If you build with 
-fno-optimize-sibling-calls a R_390_JMP_SLOT relocation is generated 
instead.
My point of view is that s390 localplt.data should be adjusted with my 
patch.
But I don't know if this relocation in general is intended or not.
If it is not then this behaviour has to be changed and the localplt.data 
files of all architectures have to be adjusted as well.

>
> I find all this rather puzzling because we really do not want to
> interpose the dl-minimal.c malloc for the whole process, and yet the
> elf/Versions file lists it …
>
> Florian
>
>
Stefan Liebler Sept. 5, 2016, 7:08 a.m. UTC | #9 
Florian,

How to proceed here?
I'd like to commit this patch this week as it's the same behaviour on 
s390 as on other architectures.
Any objection?

Bye.
Stefan


On 08/30/2016 05:52 PM, Stefan Liebler wrote:
>
>
> On 08/26/2016 01:49 PM, Florian Weimer wrote:
>> On 08/23/2016 01:28 PM, Stefan Liebler wrote:
>>> On 08/18/2016 12:42 PM, Stefan Liebler wrote:
>>>> On 08/17/2016 03:48 PM, Florian Weimer wrote:
>>>>> On 08/09/2016 04:22 PM, Stefan Liebler wrote:
>>>>>> On 08/09/2016 03:53 PM, Florian Weimer wrote:
>>>>>>> On 08/09/2016 03:34 PM, Stefan Liebler wrote:
>>>>>>>> After the commits __libc_memalign is only called in
>>>>>>>> elf/dl-minimal.c in
>>>>>>>> malloc() function in ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT
>>>>>>>> instead of R_390_JMP_SLOT. __libc_memalign is called via
>>>>>>>> function-pointer loaded from GOT instead of calling via a plt-stub.
>>>>>>>
>>>>>>> Huh.  I wonder if this is intended.  Surely the malloc
>>>>>>> implementation in
>>>>>>> elf/dl-minimal.c should always call the __libc_memalign
>>>>>>> implementation
>>>>>>> in the same file?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Florian
>>>>>>>
>>>>>>
>>>>>> Please have a look at the other localplt.data files, e.g.
>>>>>> sysdeps/x86_64/localplt.data:
>>>>>> # The dynamic loader uses __libc_memalign internally to allocate
>>>>>> aligned
>>>>>> # TLS storage. The other malloc family of functions are expected to
>>>>>> allow
>>>>>> # user symbol interposition.
>>>>>> ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT
>>>>>>
>>>>>> All contains the __libc_memalign relocation.
>>>>>> On s390x it has also existed before but a plt-stub was used. If you
>>>>>> now
>>>>>> use the compiler flag -fno-optimize-sibling-calls you'll get the
>>>>>> plt-stub as before. With this optimization the relocation is done
>>>>>> via a
>>>>>> function pointer.
>>>>>
>>>>> Okay, but shouldn't be __libc_memalign in dl-minimal.c declared as
>>>>> attribute_hidden?
>>>>>
>>>>> Thanks,
>>>>> Florian
>>>>>
>>>> I don't know. Can you simply do this as __libc_memalign is also
>>>> mentioned in elf/Versions file?
>>>> ld {
>>>>   GLIBC_2.0 {
>>>>     # Function from libc.so which must be shared with libc.
>>>>     __libc_memalign; calloc; free; malloc; realloc;
>>>>
>>>>     _r_debug;
>>>>   }
>>>>
>>>
>>> Is there any news about __libc_memalign?
>>> Otherwise I'd like to commit this patch.
>>> I think if you change something about __libc_memalign you have to touch
>>> the other architectures as well.
>>
>> Sorry, I don't feel qualified to comment on this.
>>
>> What has changes is that we no longer reference __libc_memalign, in
>> order to simplify the interposition of a custom malloc.
> Yes. Your patches removed the usage of __libc_memalign and instead used
> malloc in elf/dl-minimal.c which is the last place where __libc_memalign
> is called:
> void * weak_function
> malloc (size_t n)
> {
>   return __libc_memalign (MALLOC_ALIGNMENT, n);
> }
>
> Here is the relocation on intel, too:
> objdump -dr elf/dl-minimal.os
> 0000000000000110 <malloc>:
>  110:   48 89 fe                mov    %rdi,%rsi
>  113:   bf 10 00 00 00          mov    $0x10,%edi
>  118:   e9 00 00 00 00          jmpq   11d <malloc+0xd>
>                         119: R_X86_64_PLT32     __libc_memalign-0x4
>  11d:   0f 1f 00                nopl   (%rax)
>
> I had a further look at the __libc_memalign relocations used in ld.so ..
>
> ... before your patches:
> Relocation section '.rela.dyn'
> 000000026058  000d0000000a R_390_GLOB_DAT    000000000001b3b8
> __libc_memalign + 0
> (used in elf/dl-minimal.os in malloc function via function pointer in got)
>
> Relocation section '.rela.plt':
> 000000026018  000d0000000b R_390_JMP_SLOT    000000000001b3b8
> __libc_memalign + 0
> (used via plt-stub in tls_get_addr_tail, _dl_allocate_tls_storage,
> _dl_allocate_tls in elf/dl-tls.os)
>
>
> ... after your patches:
> Relocation section '.rela.dyn':
> 000000026050  000d0000000a R_390_GLOB_DAT    000000000001b298
> __libc_memalign + 0
> (used in elf/dl-minimal.os in malloc function via function pointer in got)
>
> => As the __libc_memalign usages in elf/dl-tls.os are removed,
> there is no call of __libc_memalign via plt-stub anymore, thus the
> testcase elf/check-localplt is failing. My patch is allowing the
> R_390_GLOB_DAT relocation as well. If you build with
> -fno-optimize-sibling-calls a R_390_JMP_SLOT relocation is generated
> instead.
> My point of view is that s390 localplt.data should be adjusted with my
> patch.
> But I don't know if this relocation in general is intended or not.
> If it is not then this behaviour has to be changed and the localplt.data
> files of all architectures have to be adjusted as well.
>
>>
>> I find all this rather puzzling because we really do not want to
>> interpose the dl-minimal.c malloc for the whole process, and yet the
>> elf/Versions file lists it …
>>
>> Florian
>>
>>
>
Florian Weimer Sept. 5, 2016, 7:23 a.m. UTC | #10 
On 09/05/2016 09:08 AM, Stefan Liebler wrote:
> Florian,
>
> How to proceed here?
> I'd like to commit this patch this week as it's the same behaviour on
> s390 as on other architectures.
> Any objection?

Not from me.  I was hoping that someone would comment who actually knows 
what's going on (i.e., why the remaining reference to __libc_memalign 
can't be hidden).

Thanks,
Florian
Stefan Liebler Sept. 6, 2016, 12:47 p.m. UTC | #11 
On 09/05/2016 09:23 AM, Florian Weimer wrote:
> On 09/05/2016 09:08 AM, Stefan Liebler wrote:
>> Florian,
>>
>> How to proceed here?
>> I'd like to commit this patch this week as it's the same behaviour on
>> s390 as on other architectures.
>> Any objection?
>
> Not from me.  I was hoping that someone would comment who actually knows
> what's going on (i.e., why the remaining reference to __libc_memalign
> can't be hidden).
>
> Thanks,
> Florian
>
Okay. Then I committed it.
Thanks.
diff mbox

Patch

diff --git a/sysdeps/unix/sysv/linux/s390/localplt.data b/sysdeps/unix/sysv/linux/s390/localplt.data
index b25abf8..1226413 100644
--- a/sysdeps/unix/sysv/linux/s390/localplt.data
+++ b/sysdeps/unix/sysv/linux/s390/localplt.data
@@ -8,7 +8,14 @@  libm.so: matherr
 # The dynamic loader uses __libc_memalign internally to allocate aligned
 # TLS storage. The other malloc family of functions are expected to allow
 # user symbol interposition.
-ld.so: __libc_memalign
+# It is also allowed to call __libc_memalign via function-pointer loaded from
+# GOT instead of calling via a plt-stub. In this case there is a R_390_GLOB_DAT
+# relocation in section .rela.dyn instead of R_390_JMP_SLOT in .rela.plt.
+# After commit "elf: Do not use memalign for TCB/TLS blocks allocation
+# [BZ #17730]" __libc_memalign is only called in elf/dl-minimal.c: malloc() in
+# ld.so and gcc -O2/-O3 leads to R_390_GLOB_DAT. If build with
+# -fno-optimize-sibling-calls an R_390_JMP_SLOT is generated.
+ld.so: __libc_memalign + RELA R_390_GLOB_DAT
 ld.so: malloc
 ld.so: calloc
 ld.so: realloc