Sprinkle nop.
This is the kernel part of addressing the issue with fpu emulation on lc040
cpus.
The idea is that we might be switch from or to an f-line (MMU/FPU Trap)
instruction so prepend a nop to flush the caches.
Addresses part of PR/13078.
The second part to this (patch to binutils/gas) has been submitted upstream
and will be fixed when this part is reviewed and included in our local copy
of binutils or (hopefully) in a later version of binutils from upstream.
See:
https://sourceware.org/pipermail/binutils/2025-March/140270.html
Always read LIF volume/directory from stage1 even on cd9660 stage2 case.
mmap(2) against the bootstrap file in the target cd9660 could fail
because the sector size of ISO9660 is 2048 so each file could be
allocated at an offset not pagesize (4096 or 8192) aligned.
This could fail if stage1 (specified via "primary" arg on command line)
and stage2 (on the target filesystem) files are different, but
in "build.sh iso-image" case they are always identical.
The problem (build failures in auotomated builds for hp300 on Linux)
was reported by Jan-Benedict Glaw.
Should also be pulled up to netbsd-10.
tests/make: fix test for printing the stack trace
Depending on the exact environment in which the test is run, the "./"
path component may or may not be trimmed from the output. Use an
absolute path instead.
make: fix error message for invalid ":[...]" modifier
The unparsed value of the modifier argument can already be seen in the
stack trace, but the modifier argument may contain expressions and the
expanded value of these expressions was hidden up to now. See the EMPTY
test at the bottom of varmod-select-words.mk for details.
strlcpy(3): Another attempt at reworking the description for clarity.
These functions have extremely sharp edges that are apparently still
inadequately documented. Put the full behaviour of both functions
more clearly up front, emphasize that src MUST be NUL-terminated up
front, and add another WARNING for another sharp edge that wasn't
made clear enough.
make: add details to error message for the "::=" modifier
The previous error message about a bad modifier ":" was not helpful, as
the strcspn call stopped immediately due to the modifier starting with
the separater character ":". The previous error message also didn't
reveal that the "parse error" was due to the expression name being
empty.
make: let the ":t" modifiers fall back to the ":from=to" modifier
Suggested by https://bugs.freebsd.org/285726.
This means that the ":t" modifiers cannot have future extensions that
include a "=", as that may break existing code.
unix(4): Comma is wrong; semicolon is right.
(Personally I would use an em dash here, but then I always render man
pages with LC_ALL=C because UTF-8 output is screwy for various other
reasons like rendering program options with characters other than
standard hyphen `-' so searching for text like `-F' doesn't work.)
ctype(3): Simplify definitions of ctype/tolower/toupper tables.
Clarify comment while here.
No functional change intended. No change to `readelf -a' output on
amd64 or aarch64.
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
make: let unknown ":O" modifiers fall back to the ":from=to" modifier
Inspired by https://bugs.freebsd.org/285726, which concerns the ":t"
modifier instead.
This means that future extensions to the ":O" modifier must not contain
a "=" anywhere, otherwise they may break existing code.
libc/isctype.c: Omit needless #include <assert.h>.
Crept in during an earlier revision when I wrote this with
_DIAGASSERT. (I opted to unconditionally abort so that you get the
feedback about undefined behaviour even if you don't run with
LIBC_DIAGASSERT set in the environment. Since it's undefined
behaviour we are allowed to do this unconditionally, of course!)
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
libc: Restore ELF symbol sizes for _C_ctype_tab_ &c.
This is needed for dynamic position-dependent executables that refer
directly to _C_type_tab_ to get correct copy relocations to see the
table content.
Unfortunately, such executables won't get a guard page.
Fortunately, referring to _C_ctype_tab_ directly (and not the
indirection _ctype_tab_ as the ctype(3) macros do) is very weird and
unlikely to happen in the real world (none of the public interfaces
use it; it is exported for libc++.so/libstdc++.so to use, but those
aren't pies). So missing the guard page in this case is probably not
so bad.
The symbol sizes are also needed for, e.g., gdb to nicely identify
addresses that lie in the table.
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
tests/make: fix the documented modifier table
The SysV column was largely incorrect or too unspecific, stating N/A
when "no" was actually correct.
The modifiers differ in whether they fall back to the ":from=to"
modifier. The suggestion in https://bugs.freebsd.org/285726 to make more
of the modifiers fall back to the ":from=to" modifier thus becomes
nonobvious to decide.
ctype(3): Put guard pages before the C ctype/tolower/toupper tables.
This also only affects machines where char is signed for now. (But
maybe it would be worth doing unconditionally; users could still try
to pass in explicit `signed char' inputs.)
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
make: add ":" to error message about unknown modifier
In the manual page, the modifiers are listed with a preceding ":", so
use the same pattern in the error message. This removes an inconsistency
between the error messages "Unknown modifier" and "Bad modifier".
tests/make: remove copy-and-paste errors from warning messages
Several of the warnings didn't match what they actually tested, so
remove them all to prevent further disagreements.
make: stop parsing after seeing an unknown modifier in an expression
Previously, after an expression such as ${VAR:Z::::}, make detected the
unknown modifier ":Z" and then continued parsing, which produced
unnecessary follow-up error messages. It was also necessary to
distinguish the error cases when logging the result of an applied
modifier in -dv mode.
Unify the error handling cases of a syntax error, an evaluation error
and an unknown modifier, to avoid the unnecessary follow-up error
messages.
The test in varmod-edge.mk now produces ":}" from the erroneous
expression, which may be misleading and thus will be looked at in a
follow-up commit.
The general idea of this patch was reviewed by sjg, I made a few
nonsubstantial changes after the review.
__predict_true/false: Make these work with C++ too.
Should fix build after recent assert.h change.
error: no match for `operator!=' (operand types are `...' and `int')
PR lib/59231: assert.h: missing branch prediction
make: fix error message for unclosed expression
Even in an unclosed expression such as "${VAR:from=to", the modifier
":from=to" needs to be recognized as such, instead of giving an error
message about an "Unknown modifier ":from=to"".
make: add more details to error message about unfinished modifier
These details allow to quickly see the place where the syntax error is,
based on the surrounding lines from the stack trace.
make: add details about indirect modifiers to the stack traces
Previously, the error message "Unfinished modifier (',' missing)" from
moderrs.mk didn't provide enough context to understand where and why the
comma was missing.
Pull up following revision(s) (requested by gutteridge in ticket #1078):
share/installboot/evbarm/boards.plist: revision 1.11
evbarm/boards.plist: add three more boards
FriendlyElec NanoPi R2S
PineCube IP Camera
TI AM335x BeagleBone Green
