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