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
On second thought, don't use __mc68010__ throughout as a proxy for
"is a Sun-2"; it's too easy to glance-misread #ifdef vs #ifndef.
Instead, define IS_SUN2 and IS_SUN3 macros that statically evaluate
to the right thing and use them throughout.
Pull up following revision(s) (requested by riastradh in ticket #391):
libexec/ld.elf_so/rtld.c: revision 1.228
libexec/ld.elf_so/xmalloc.c: revision 1.27
ld.elf_so: Fix reversed sense of previous change to ASSERT macro.
Had tested the part of the change replacing botch("p") by botch(#p);
then didn't test the change from `if (!(p)) botch(#p)' to
`(__predict_false(p) ? botch(#p) : (void)0)'. Oops.
Now I have tested this with MALLOC_DEBUG enabled in ld.elf_so.
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
ld.elf_so: Set _rtld_objself.refcount = 1.
This is the object for ld.elf_so itself. It can be opened with
[17 lines not shown]
Pull up following revision(s) (requested by kre in ticket #390):
external/mit/xorg/lib/driver.old.mk: revision 1.3
external/mit/xorg/lib/driver.mk: revision 1.10
PR xsrc/59858 (locale fixes for xsrc)
From RVP - see the PR
Oversimplifying: this causes Mesa to use LC_NUMERIC=C when using
strtod() to parse stuff (ie: the radix char (decimal point) is '.',
regardless of the user's locale).
Pull up following revision(s) (requested by kre in ticket #389):
usr.bin/xinstall/xinstall.c: revision 1.131
PR bin/58577 - install(1) -d issues
Fix issues where "install -d" (with no directory) simply
exit(0)s. That one is kind of marginal, installing nothing
when nothing is needed could be treated as OK, but the man
page does indicate in the SYNOPSIS that with -d, at least
one directory is needed (it says nothing at all about that
in the text).
Second, after creating a directory, if a later operation
(chown, chmod) fails, that is not success, a warning was
issued (good), a bad metalog was being created (bad).
That is clearly a bug (though probably doesn't happen
very often).
[28 lines not shown]
Pull up following revision(s) (requested by kre in ticket #388):
lib/libc/locale/runetable.c: revision 1.30
lib/libc/locale/iswctype_mb.c: revision 1.15
PR lib/59067 (wctrans got error member)
Patches from the OP (ru_j217) and from RVP - see the PR
This looks to be just correcting what appear to be simple
errors in the code.
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
ld.elf_so: Flip on DEBUG in current.
This enables assertions (and the LD_DEBUG environment variable).
We can disable it in release branches to reduce performance impact,
but let's not have the assertions bitrot in current.
Prompted by diagnosing fallout from:
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
ld.elf_so: Set _rtld_objself.refcount = 1.
This is the object for ld.elf_so itself. It can be opened with
dlopen("/usr/libexec/ld.elf_so"), and paths downstream of that assert
that the returned object has refcount > 0 to detect use-after-free
mistakes in rtld. Since ld.elf_so must never be unloaded, let's just
make sure the reference count is always positive.
(It's conceivable that one could dlopen an object with a DT_RPATH
entry having "/usr/libexec" and a DT_NEEDED entry having "ld.elf_so",
causing recursive loading of ld.elf_so -- and if one then dlcloses
the same object, it might lead to trying to free _rtld_objself. So
perhaps _rtld_load_object should just increment the reference count
of _rtld_objself itself. But this is a simpler change that already
fixes some existing tests -- such as any rump tests -- when used with
an ld.elf_built with -DDEBUG.)
Followup for:
[2 lines not shown]
ld.elf_so: Fix reversed sense of previous change to ASSERT macro.
Had tested the part of the change replacing botch("p") by botch(#p);
then didn't test the change from `if (!(p)) botch(#p)' to
`(__predict_false(p) ? botch(#p) : (void)0)'. Oops.
Now I have tested this with MALLOC_DEBUG enabled in ld.elf_so.
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
sh: Revert the -i/-m change
This apparently breaks the automated installs. I will need to
look at it more closely (and it was such a trivial little change!)
Pull up following revision(s) (requested by riastradh in ticket #382):
external/bsd/unbound/etc/rc.d/unbound: revision 1.4
/etc/rc.d/unbound: Fix order of migration and trust anchor setup.
Add some comments explaining the order, and make sure we propagate
various failures back to the caller.
Based on a patch by Erik LaBine.
PR bin/60447: unbound rc.d fails on fresh install before
configuration migration can run
Pull up the following, requested by kre in ticket #387:
external/public-domain/tz/dist/Makefile up to 1.6
external/public-domain/tz/dist/NEWS up to 1.8
external/public-domain/tz/dist/TZDATA_VERSION up to 1.46
external/public-domain/tz/dist/africa up to 1.4
external/public-domain/tz/dist/australasia up to 1.13
external/public-domain/tz/dist/europe up to 1.6
external/public-domain/tz/dist/leap-seconds.list up to 1.12
external/public-domain/tz/dist/leapseconds up to 1.12
external/public-domain/tz/dist/northamerica up to 1.7
external/public-domain/tz/dist/theory.html up to 1.6
external/public-domain/tz/dist/version up to 1.19
external/public-domain/tz/dist/ziguard.awk up to 1.1.1.12
external/public-domain/tz/dist/zone.tab up to 1.6
external/public-domain/tz/dist/zone1970.tab up to 1.7
external/public-domain/tz/dist/zonenow.tab up to 1.8
Import tzdata2026cgtz
/bin/sh - fix a comment
The showjobs() function once (long ago) had a parameter "change"
which caused it to only show jobs whose status had altered since the
last call. It has since (in 2002) had that parameter's name changed
to "mode" and become a bit field, one of the bits of which is
SHOW_CHANGED, which when set does what the old change parameter did.
However, the comment that describes the function wasn't updated to match.
Now it has been. NFC.
Pull up following revision(s) (requested by thorpej in ticket #385):
sys/arch/sparc/conf/GENERIC: revision 1.277
sys/dev/sbus/if_gem_sbus.c: revision 1.16
Adapt the SBus config register for 32-bit SPARC systems and enable
GEM Ethernet in the GENERIC SPARC configuration.
From Erik LaBine.
PR kern/60453
Pull up following revision(s) (requested by thorpej in ticket #384):
sys/arch/sparc/sparc/iommu.c: revision 1.103
Add support for bus_dmamap_load_mbuf(), needed to support GEM Ethernet.
From Erik LaBine.
PR kern/60453
/bin/sh - minor -i & -m changes
When enabling job control (set -m) at the top level (not in any kind
of subshell) in a non-interactive shell, sh would sometimes send itself
a SIGTTIN (suspending itself) if it was unable to grab the controlling
terminal. Only interactive shells should be concerned with that,
so an interactive sh placed in the background, trying to manipulate
the controlling tty will simply suspend, until it is resumed in fg.
Scripts shouldn't need to care.
So only do controlling tty manipulation in interactive shells (-i is set).
While here, clean up the manual description of the -i flag, setting it on
the command line does not always make a shell interactive (the shell will
simply clear it if it is inappropriate), but clearing it (+i) always
prevents the shell becoming interactive. Manipulating it later using
'set' (which is a non-standard usage) is not recommended, and can cause
the shell to behave in unexpected ways, so advise against attempts to
do so (in the manual).
[3 lines not shown]
