| Message ID | fbddd3a3-9d00-8b56-e5ed-c360ccbe28ae@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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; }
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
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
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, 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 >> >> >
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
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 --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