ld.elf_so: Prune some dead TLS variant branches.
__lwp_settcb / __lwp_gettcb_fast are used only with TLS variant I,
never with TLS variant II.
So say `#ifdef __HAVE_TLS_VARIANT_II' instead of `#ifndef
__HAVE_TLS_VARIANT_I' to make it clearer, and prune all the
__HAVE___LWP_SETTCB / __HAVE___LWP_GETTCB_FAST branches under it
because they're unreachable.
No functional change intended: all the deleted code should be dead.
PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333
ld.elf_so: Fix assertions for TLS variant I without _lwp_settcb.
In variant I, the TLS address is always
(uint8_t *)tcb + sizeof(struct tls_tcb) + obj->tlsoffset.
With _lwp_settcb, (uint8_t *)tcb + sizeof(struct tls_tcb) is aligned,
whereas without it, (uint8_t *)tcb is aligned. Consequently, with
_lwp_settcb, obj->tlsoffset must also be aligned, whereas without it,
obj->tlsoffset + sizeof(struct tls_tcb) must be aligned -- and hence,
without _lwp_settcb, obj->tlsoffset must be congruent to
-sizeof(struct tls_tcb) modulo the alignment.
No functional change intended for non-DEBUG builds: assertion changes
only here.
PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333
Expand option FFS_NO_SNAPSHOT to completely remove snapshot support.
File systems with snapshots cannot be mounted read/write to prevent
damage to snapshots.
PR kern/60456 "FFS_NO_SNAPSHOT option is not entirely effective"
Pull up following revision(s) (requested by riastradh in ticket #393):
libexec/ld.elf_so/search.c: revision 1.30
libexec/ld.elf_so/xmalloc.c: revision 1.28
libexec/ld.elf_so/tls.c: revision 1.30
libexec/ld.elf_so/tls.c: revision 1.31
libexec/ld.elf_so/search.c: revision 1.29
ld.elf_so: Fix assertion: obj may be NULL _or_ OBJ_ERR (-1) here
NULL means the object wasn't found and we should keep searching;
OBJ_ERR means the object was found but loading it failed and we
should stop. Only if the object is _neither_ NULL _nor_ OBJ_ERR is
it expected to be an object with positive refcount.
Followup for
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
[43 lines not shown]
ld.elf_so: Fix one more mistake in handling _rtld_load_object.
This can return NULL (meaning object not found or something went wrong
with the object) or OBJ_ERR (meaning the object has DF_1_NOOPEN set or
the caller passed RTLD_NOLOAD to dlopen() and the object was not
already loaded) or a valid object.
I reviewed all paths out of _rtld_load_object to make sure they
gracefully handle all three cases (NULL, OBJ_ERR, valid object), and
this assertion was the only path that didn't.
Fixes buggy assertion added for:
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
May fix:
PR bin/60472: ld.elf_so(1) changes cause a segmentation fault in
dlopen(3)
ld.elf_so: Mark new variables __debugused, not __diagused.
They are used in ld.elf_so builds with DEBUG, not with DIAGNOSTIC!
PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333
ld.elf_so: Fix static TLS alignment on variant II platforms.
Only affects obscure architectures like x86, though.
Sprinkle assertions to make sure this breaks in other ways on other
architectures too, like variant I, or variant II with _lwp_gettcb().
Fair's fair, right?
XXX We should consider verifying that every Elf_Phdr::p_align is
reasonable (i.e., is a power of two, or is zero but only if p_memsz
is also zero), and that p_filesz <= p_memsz, in headers.c for the
main object and in map_object.c for other objects.
PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333
