this change was suggested based on testing done by Timo Teräs almost
two years ago; the branch (and probably call prep overhead) in the
inner loop was found to contribute noticably to total symbol lookup
time. this change will make lookup slightly slower if libraries were
built with only the traditional "sysv" ELF hash table, but based on
how much slower lookup tends to be without the gnu hash table, it
seems reasonable to assume that (1) users building without gnu hash
don't care about dynamic linking performance, and (2) the extra time
spent computing the gnu hash is likely to be dominated by the slowness
of the sysv hash table lookup anyway.
partly following freebsd rev 279491
https://svnweb.freebsd.org/base?view=revision&revision=279491
(musl had some of the fixes before freebsd).
the change should not matter much for j0f, y0f, but it improves
j1f and y1f in [2.5,~3.75] (that is [0x40200000,~0x40700000]).
near roots (e.g. around 3.8317 for j1f) there are still large
ulp errors.
dropped code that tried to raise inexact.
such loading is unsafe, and can happen when programs use their own
logic to locate a .so file then pass the absolute pathname to dlopen,
or if an absolute pathname ends up in DT_NEEDED headers. multiple
loads with only the base name were already precluded, provided libc
was named appropriately, by special-casing standard library names.
one function symbol (in the reserved namespace, but public, since it's
part of the crt1 entry point ABI) and one data symbol are checked.
this way we avoid likely false positives, particularly from libraries
interposing and wrapping functions. there is no hard requirement to
avoid breaking such usage, since trying to run a hook before libc is
even initialized is not a supported usage case, but it's friendlier
not to break things.
the fix in commit c3edc06d1e for
CVE-2016-8859 used gotos to exit on overflow conditions, but the code
in that error path assumed the buffer pointer was valid or null. thus,
the conditions which previously led to under-allocation and buffer
overflow could instead lead to an invalid pointer being passed to
free.
traditional lazy relocation with call-time plt resolver is
intentionally not implemented, as it is a huge bug surface and demands
significant amounts of arch-specific code and requires ongoing
maintenance to ensure compatibility with applications which make use
of new additions to the arch's register file in passing function
arguments.
some applications, however, depend on the ability to dlopen modules
which have unsatisfied symbol references at the time they are loaded,
either avoiding use of the affected interfaces or manually loading
another module to provide the missing definition via their own module
dependency tracking outside the ELF data structures. while such usage
is non-conforming, failure to support it has been a significant
obstacle for users/distributions trying to support affected software,
particularly the X.org server.
instead of resolving lazy relocations at call time, this patch saves
unresolved GOT/PLT relocations for deferral and retries them after
each subsequent dlopen until they are resolved. since dlopen is the
only time at which the effective global symbol table can change, this
behavior is not observably different from traditional lazy binding,
and the required code is minimal.
when loading libraries with dlopen, the caller can request that the
library's symbols become part of the global symbol table, or that they
only be used for resolving relocations in the loaded library and its
dependencies. in the latter case, a subsequent dlopen of the same
library can upgrade it to global status.
previously, if a library was upgraded from local to global mode, its
symbols entered the symbol lookup search order at the point where the
library was originally loaded. this means that a new call to dlopen
could change the value of a symbol that already had a visible
definition, an inconsistency which applications could observe.
POSIX is unclear whether this should happen or whether it's permitted
to happen, but the resolution of Austin Group issue #982 made it
formally unspecified.
with this patch, a library whose mode is upgraded from local to global
enters the symbol lookup order at the point where it was made global,
so that symbol resolution before and after the upgrade are consistent.
in order to implement this change, the per-dso global flag is replaced
with a separate set of linked-list pointers for participation in the
global symbol table. this permits the order of dso objects for symbol
resolution to differ from the order used for iteration of all loaded
libraries. it also improves performance of find_sym, by avoiding a
branch per iteration and skipping, and especially in the case where
many non-global libraries have been loaded, by allowing the loop to
skip over them entirely. logic for temporarily adding non-global
libraries to the symbol table for relocation purposes is also mildly
simplified.
A weak symbol definition is not special during dynamic linking, so
don't let a strong definition in a later module override it.
(glibc dynamic linker allows overriding weak definitions if
LD_DYNAMIC_WEAK is set, musl does not.)
STB_GNU_UNIQUE means that the symbol is global, even if it is in a
module that's loaded with RTLD_LOCAL, and all references resolve to
the same definition. This semantics is only relevant for c++ plugin
systems and even there it's often not what the user wants (so it can
be turned off in g++ by -fno-gnu-unique when the c++ shared lib is
compiled). In musl just treat it like STB_GLOBAL.
the 32-bit pc-relative address for stage 2 of dynamic linker entry was
wrongly loaded with a zero-extending load instead of sign-extending
load, resulting in an invalid jump if the offset happened to be
negative, which depends on the linker's ordering of text sections.
this is not a conformance issue as posix does not specify the
argument order, but the order is specified for bsearch and some
systems document the order for lsearch consistently (openbsd).
since there were two indpendent reports of this issue it's better
to use the more widely expected argument order.
the ABI for arm was silently changed at some point to allow page sizes
other than 4k; traditional binaries built with only 4k-aligned offsets
between load segments cannot run on such systems, but newer binutils
versions use 64k offset alignment.
while larger page size is undesirable for various reasons, users have
encountered hardware and/or kernels that lock the page size to a
larger value, so follow the new ABI and allow it to vary.
binutils commit bada43421274615d0d5f629a61a60b7daa71bc15 tightened
immediate fixup handling in gas in such a way that the final .arch of
an object file must be compatible with the fixups used when the
instruction was assembled; this in turn broke assembling of atomics.s,
at least in thumb mode.
it's not clear whether this should be considered a bug in gas, but
.object_arch is preferable anyway for our purpose here of controlling
the ISA level tag on the object file being produced, and it's the
intended directive for use in object files with runtime code
selection. research by Szabolcs Nagy confirmed that .object_arch is
supported in all relevant versions of binutils and clang's integrated
assembler.
patch by Reiner Herrmann.
the plural_rule field of allocated msgcat structures was assumed to be
initially-null but was never initialized. for future-proofing, the
nplurals field which was left uninitialized should also be cleared.
likewise, in the binding structure, the active field could be used
uninitialized by a technicality: the a_store which stores the initial
value of 0 may be implemented as a cas operation, which reads the old
value.
rather than fixing these issues individually, just use calloc for both
allocations. this does result in wasteful clearing of name buffers (up
to NAME_MAX+PATH_MAX) before filling them, but since the size if
bounded and the time is dominated by filesystem operations, it really
doesn't matter; simplicity and future-proofing have more value here.
modified from patch submitted by He X.
this loop was only supposed to deactivate other bindings for the same
text domain name, but due to copy-and-paste error, deactivated all
other bindings.
patch by He X.
commit 78a8ef47c4 inadvertently removed
the SA_RESTART flag from the sigaction for the internal signal handler
used by __synccall for broadcasting. as a result, programs which did
not use interrupting signals but which used set*id() in a
multithreaded context could wrongly observe EINTR errors they're not
prepared to handle.
commit d56460c939 introduced this
regression as part of splitting the tls module list out of the dso
list. the new code added to dlopen's failure path to undo the changes
adding the partially-loaded libraries reset the tls_tail pointer
correctly, but did not clear its link to the next list entry. thus, at
least until the next successful dlopen, the list was not terminated
but ended with an invalid next pointer, which __copy_tls attempted to
follow when a new thread was created.
patch by Mikael Vidstedt.
ISO C and POSIX only specify behavior for base arguments of 0 and
2-36; POSIX mandates an EINVAL error for unsupported bases. it's not
clear that there's a requirement for implementations not to "support"
additional bases as an extension, but "base 1" did not work in any
meaningful way anyway, so it should be considered unsupported and thus
an error.
getopt is only specified to modify optopt on error, and some software
apparently infers an error from optopt!=0.
getopt_long is changed analogously. the resulting behavior differs
slightly from the behavior of the GNU implementation of getopt_long,
which keeps an internal shadow copy of optopt and copies it to the
public one on return, but since the GNU implementation also exhibits
this shadow-copy behavior for plain getopt where is is non-conforming,
I think this can reasonably be considered a bug rather than an
intentional behavior that merits mimicing.
when _GNU_SOURCE is defined, which is always the case when compiling
c++ with gcc, these macros for the the indices in gregset_t are
exposed and likely to clash with applications. by using enum constants
rather than macros defined with integer literals, we can make the
clash slightly less likely to break software. the macros are still
defined in case anything checks for them with #ifdef, but they're
defined to expand to themselves so that non-file-scope (e.g.
namespaced) identifiers by the same names still work.
for the sake of avoiding mistakes, the changes were generated with sed
via the command:
sed -i -e 's/#define *\(REG_[A-Z_0-9]\{1,\}\) *\([0-9]\{1,\}\)'\
'/enum { \1 = \2 };\n#define \1 \1/' \
arch/i386/bits/signal.h arch/x86_64/bits/signal.h arch/x32/bits/signal.h
commit 0dc99ac413 added input length
checking to avoid unsafe VLA allocation, but put it in the wrong
place, before the glob_t structure was zeroed out. while POSIX isn't
clear on whether it's permitted to call globfree after glob failed
with GLOB_NOSPACE, making it safe is clearly better than letting
uninitialized pointers get passed to free in non-conforming callers.
while we're fixing this, change strlen check to the idiomatic strnlen
version to avoid unbounded input scanning before returning an error.
commit 583ea83541 fixed the case where
tm_year is negative but the resulting year (offset by 1900) was still
positive, which is always the case for time_t values that fit in 32
bits, but not for arbitrary inputs.
based on an earlier patch by Julien Ramseier which was overlooked at
the time the previous fix was applied.
the static-linked version of __init_tls needs to locate the TLS
initialization image via the ELF program headers, which requires
determining the base address at which the program was loaded. the
existing code attempted to do this by comparing the actual address of
the program headers (obtained via auxv) with the virtual address for
the PT_PHDR record in the program headers. however, the linker seems
to produce a PT_PHDR record only when a program interpreter (dynamic
linker) is used. thus the computation failed and used the default base
address of 0, leading to a crash when trying to access the TLS image
at the wrong address.
the dynamic linker entry point and static-PIE rcrt1.o startup code
compute the base address instead by taking the difference between the
run-time address of _DYNAMIC and the virtual address in the PT_DYNAMIC
record. this patch copies the approach they use, but with a weak
symbolic reference to _DYNAMIC instead of obtaining the address from
the crt_arch.h asm. this works because relocations have already been
performed at the time __init_tls is called.
all assembly is now thumb2-compatible. on existing targets this is at
best a size optimization, but it will also facilitate porting to
thumb2-isa-only arm variants.
three problems are addressed:
- use of pc arithmetic, which was difficult if not impossible to make
correct in thumb mode on all models, so that relative rather than
absolute pointers to the backends could be used. this was designed
back when there was no coherent model for the early stages of the
dynamic linker before relocations, and is no longer necessary.
- assumption that data (the relative pointers to the backends) can be
accessed at a constant displacement from the code. this will not be
possible on future fdpic subarchs (for cortex-m), so move
responsibility for loading the backend code address to the caller.
- hard-coded arm opcodes using the .word directive. instead, use the
.arch directive to work around the assembler's refusal to assemble
instructions not available (or in some cases, available but just
considered deprecated) in the target isa level. the obscure v6t2
arch is used for v6 code so as to (1) allow generation of thumb2
output if -mthumb is active, and (2) avoid warnings/errors for mcr
barriers that clang would produce if we just set arch to v7-a.
in addition, the __aeabi_read_tp function is moved out of the inner
workings and implemented as an asm wrapper around a C function, so
that asm code does not need to read global data. the asm wrapper
serves to satisfy the ABI calling convention requirements for this
function.
float conversion is slow and big on soft-float targets.
The lookup table increases code size a bit on most hard float targets
(and adds 60byte rodata), performance can be a bit slower because of
position independent data access and cpu internal state dependence
(cache, extra branches), but the overall effect should be minimal
(common, small size allocations should be unaffected).
In BRE, ^ is an anchor at the beginning of an expression, optionally
it may be an anchor at the beginning of a subexpression and must be
treated as a literal otherwise.
Previously musl treated ^ in subexpressions as literal, but at least
glibc and gnu sed treats it as an anchor and that's the more useful
behaviour: it can always be escaped to get back the literal meaning.
Same for $ at the end of a subexpression.
Portable BRE should not rely on this, but there are sed commands in
build scripts which do.
This changes the meaning of the BREs:
\(^a\)
\(a\|^b\)
\(a$\)
\(a$\|b\)
POSIX specifies the result to have signed 32-bit range. on 32-bit
archs, the implicit conversion to long achieved the desired range
already, but when long is 64-bit, a cast is needed.
patch by Ed Schouten.
the bz instruction that was wrongly used only admits a small immediate
displacement and cannot be used with external symbols; apparently the
linker fails to diagnose the overflow.
this has been slated for removal for a long time. there is
fundamentally no way to implement stdarg without compiler assistance;
any attempt to do so has serious undefined behavior; its working
depends not just (as a common misconception goes) on ABI, but also on
assumptions about compiler code generation internal to a translation
unit, which is not subject to external ABI constraints.
gdb can only backtrace/unwind across signal handlers if it recognizes
the sa_restorer trampoline. for x86_64, gdb first attempts to
determine the symbol name for the function in which the program
counter resides and match it against "__restore_rt". if no name can be
found (e.g. in the case of a stripped binary), the exact instruction
sequence is matched instead.
when matching the function name, however, gdb's unwind code wrongly
considers the interval [sym,sym+size] rather than [sym,sym+size).
thus, if __restore_rt begins immediately after another function, gdb
wrongly identifies pc as lying within the previous adjacent function.
this patch adds a nop before __restore_rt to preclude that
possibility. it also removes the symbol name __restore and replaces it
with a macro since the stability of whether gdb identifies the
function as __restore_rt or __restore is not clear.
for the no-symbols case, the instruction sequence is changed to use
%rax rather than %eax to match what gdb expects.
based on patch by Szabolcs Nagy, with extended description and
corresponding x32 changes added.
On s390x, the kernel provides AT_SYSINFO_EHDR, but sets it to zero, if the
program being run does not have a program interpreter. This causes
problems when running the dynamic linker directly.
Rich Felker
Szabolcs Nagy
Bobby Bingham
rofl0r
Quentin Rameau