GCC 4.5 warns about "extern void _end; &end;".
Use char[] instead, as that also doesn't fall foul
of a target's .sdata optimizations.
Signed-off-by: Richard Henderson <rth@twiddle.net>
If we should use further fields in the e_ident array in the ELF header
of files we want zero to mean the default. Enforce zero for now so
that non-optional features indicated by nonzero values are not go
unnoticed when using an old dynamic linker.
If a binary gets invoked by passing it as argument to ld.so the stack
still holds the auxiliary vector of ld.so when entering the _start
routine of the executable. So the invocation via ld.so is not fully
transparent to the executable. This causes problems if the executable
wants to scan the auxv itself.
On some architectures the update of the l_used field in the lookup
functions races with setting the other bits in the bitfield. Simply
avoid this and optimize use of l_used in general.
This patch fixes mixed SSE/AVX audit and checks AVX only once in
_dl_runtime_profile. When an AVX or SSE register value in pltenter is
modified, we have to make sure that the SSE part value is the same in both
lr_xmm and lr_vector fields so that pltexit will get the correct value
from either lr_xmm or lr_vector fields. AVX-enabled pltenter should
update both lr_xmm and lr_vector fields to support stacked AVX/SSE
pltenter functions.
SSE registers are used for passing parameters and must be preserved
in runtime relocations. This is inside ld.so enforced through the
tests in tst-xmmymm.sh. But the malloc routines used after startup
come from libc.so and can be arbitrarily complex. It's overkill
to save the SSE registers all the time because of that. These calls
are rare. Instead we save them on demand. The new infrastructure
put in place in this patch makes this possible and efficient.
There were several issues when the initial 31 entries hashtab filled up.
size * 3 <= tab->n_elements is always false, table can't have more elements
than its size. I assume from libiberty/hashtab.c this meant to be check for
3/4 full. Even after fixing that, _dl_higher_prime_number (31) apparently
returns 31, only _dl_higher_prime_number (32) returns 61. And, size
variable wasn't updated during reallocation, which means during reallocation
the insertion of the new entry was done into a wrong spot.
All this lead to a hang in ld.so, because a search with n_elements 31 size
31 wouldn't ever terminate.
