Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use `xorl %eXX,%eXX' instead of `xorq %rXX,%rXX'.
=> Same effect, one byte shorter, breaks dep chain on more uarches.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
Both variants should use iwlwifi-6000g2b-6 not iwlwifi-6000g2a-6. (It
seems only two specific product variants use iwlwifi-6000g2a-6. We
could simplify by reversing the sense of the test, as OpenBSD does, but
it doesn't seem to matter much, as what we now match seems to be the
full gamut possible, so the simpler diff was chosen here.)
Addresses PR kern/58105 from wandrien.dev@gmail.com, with the
PCI_PRODUCT_INTEL_WIFI_LINK_130_1 match tested by the reporter. Code
inspection of the FreeBSD driver indicates we should safely be able to
match PCI_PRODUCT_INTEL_WIFI_LINK_130_2 also.
- Use ?=, not =, so mk.conf setting wins.
- Write out per-architecture tabular settings, not a conditional.
- Add comments for the architectures that look like they should have
sljit but don't. (XXX Missing comments about powerpc and mips --
not sure why, is this because modules don't yet work on those
architectures, or what?)
Tidying for PR 58103: bpfjit.kmod is not built on aarch64.
Make sure there's only one copy of the conditional, in bsd.own.mk;
just make sys/modules/Makefile conditional on MKSLJIT so we don't
have to keep these in sync.
As a workaround for PR 58106, tweak the conditional definition of
SLJIT_CACHE_FLUSH to use cpu_icache_sync_range only in _HARDKERNEL,
and use __builtin___clear_cache in userland and in rump kernels.
PR 58103: bpfjit.kmod is not built on aarch64
While here, reduce some diffs arising from ordering and formatting
between these architectures.
Only difference between evbarm and aarch64 now is /dev/vchiq. Not
sure offhand if it makes sense on aarch64 or only 32-bit Arm.
PR port-amd64/58093: /dev/efi missing on x86
PR port-arm/58100: /dev/ttyVI* missing on aarch64
PR port-arm/58101: /dev/nvme* missing on aarch64
PR port-arm/58102: /dev/raid* missing on aarch64
On Cygwin, the path '/././..././' is normalized before being passed to
the child 'make' process. Since overly long pathnames are not required
to be supported on all platforms, remove the test.
1. For tools that use elftoolchain: always use elftoolchain's
elfdefinitions.h. Don't even think about looking at the host's
sys/exec_elf.h, which makes no sense and should never happen.
(ELF tools that don't use elftoolchain, like m68k-elf2coff,
continue to use nbincludes/sys/exec_elf.h. But no more nbincludes
hacks in elftoolchain.)
2. For kernel components (solaris, zfs, dtrace): always use
sys/exec_elf.h, even in Solaris components via sys/elf.h.
elfdefinitions.h is not wired up in the kernel build at all.
3. For most userland components that involve libelf: use
elfdefinitions.h via libelf header files (libelf.h, gelf.h).
libdtrace in particular requires _all_ R_* reloc type definitions,
but sys/exec_elf.h brings in only the _current machine's_ R_*
reloc type definitions. (While here: Use uintptr_t instead of
Elf_Addr for pointer-to-integer cast, since Elf_Addr is MD and
provided only by sys/exec_elf.h, not by elfdefinitions.h.)
And most userland components using libelf don't rely on any
properties of the current machine from sys/exec_elf.h, so they can
use libelf's elfdefinition.h.
Exceptions:
- dtrace drti.c relies on link.h -> link_elf.h -> sys/exec_elf.h,
but it also relies on sys/dtrace.h -> sys/elf.h ->
elfdefinitions.h like other userland components using sys/elf.h.
- kdump-ioctl.c uses sys/exec_elf.h directly and sys/dtrace.h ->
sys/elf.h -> elfdefinitions like other userland components using
sys/elf.h.
- t_ptrace_wait.c (via t_ptrace_core_wait.h) uses libelf to parse
core files, but relies on sys/exec_elf.h for struct
netbsd_elfcore_procinfo.
None of these exceptions needs all R_* reloc type definitions, so
as a workaround, we can just suppress libelf's elfdefinitions.h by
defining _SYS_ELFDEFINITIONS_H_ and use sys/exec_elf.h in these
exceptions.
And undo the whole BUILTIN_ELF_HEADERS mistake. This was:
- half bogus workarounds for missing build_install dependencies in
tools/Makefile, which are no longer missing now, and
- half futile attempt to use src/sys/sys/exec_elf.h via nbincludes in
tools involving libelf instead of libelf's elfdefinitions.h, which
collides.
Longer-term, we may wish to unify sys/exec_elf.h and libelf's
elfdefinitions.h, so we don't have to play these games.
But at least now the games are limited to three .c files (one of
which is generated by Makefile.ioctl-c), rather than haphazardly
applied tree-wide by monstrous kludges in widely used .h files with
broken hackarounds to get the tools build lurching to completion.
of just writing the driver's map into the hardware ( which may have been
modified by the likes of wsfb )
With this we get a readable console even when exiting X in a less than
graceful manner.
riastradh