| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
of softfloat.c shortly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modern compiler toolchains are capable of optimizing even across
translation unit boundaries, so simply moving the memory clearing into
a separate function is not guaranteed to clear memory.
To avoid this, we take advantage of ELF weak symbol semantics, and
insert a call to an empty, weakly named function. The semantics of
calling this function aren't determinable until load time, so the
compiler and linker need to keep the memset() call.
There are still ways a toolchain might defeat this trick (e.g.,
optimistically expecting the weak symbol to not be overloaded, and
only calling memset() if it is; promoting weak symbols to strong
symbols at link-time when emitting a static binary because they won't
be interposed; implementing load-time optimizations). But at least
for the foreseeable future, these seem unlikely.
ok deraadt
|
| | |
|
| |
|
|
|
|
|
| |
this hardware alive is becoming increasingly difficult, and I should heed the
message sent by the three disks which have died on me over the last few days.
Noone sane will mourn these ports anyway. So long, and thanks for the fish.
|
| |
|
|
|
| |
libkern srandom() API since it is not suitable for this use.
ok kettenis miod
|
| |
|
|
| |
ok guenther
|
| |
|
|
|
| |
from FreeBSD
ok mikeb@ haesbaert@ deraadt@
|
| | |
|
| | |
|
| |
|
|
| |
bcopy() and memcpy() wrappers.
|
| |
|
|
| |
memcpy() or memmove().
|
| |
|
|
|
| |
and memmove() to be incorrect for copies of 32 bytes or more, when the source
and destination addresses are nicely aligned.
|
| |
|
|
| |
Do not bogusly return NULL if dst == src (spotted by tedu@)
|
| |
|
|
| |
Return the original destination pointer in memcpy() and memmove().
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
tested by beck
|
| | |
|
| |
|
|
| |
tested by bcallah, proofed by jasper, ok tedu
|
| |
|
|
| |
desired semantics. ok deraadt
|
| |
|
|
|
|
| |
previous commit.
ok deraadt@
|
| |
|
|
|
| |
Now deficient architectures can use this if they need to.
conf/files already tries to pull this in (pointed out by mlarkin)
|
| | |
|
| |
|
|
| |
checked over by mlarkin
|
| |
|
|
|
|
| |
likely to be in the cache (like how the explanation is split between
multiple commits?)
tested by various
|
| |
|
|
| |
ok .... I guess noone, because it is summer
|
| |
|
|
| |
ok mlarkin tedu
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
for overlapping copies. Attempt to be instruction cache friendly by turning
things around and make memcpy(9) use the forward copy branch of memmove(9),
and implement bcopy(9) by swapping its arguments and dropping into memmove(9).
Same change as the one just made to for hppa.
|
| |
|
|
| |
ok kettenis
|
| | |
|
| |
|
|
|
|
|
|
| |
for overlapping copies. Attempt to be instruction cache friendly by turning
things around and make memcpy(9) use the forward copy branch of memmove(9),
and implement bcopy(9) by swapping its arguments and dropping into memmove(9).
ok deraadt@
|
| |
|
|
| |
version.
|
| |
|
|
| |
ok kettenis@
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
kgmon(8) to deal with them, this time without public header changes.
Previously various CPUs were iterating over the same global buffer at
the same time to modify it and never ended.
This diff includes some ideas submited by Thor Simon to NetBSD via miod@.
ok deraadt@, mikeb@, haesbaert@
|
| |
|
|
| |
at this moment.
|
| |
|
|
|
|
|
|
|
| |
various CPUs were iterating over the same global buffer at the same
time to modify it and never ended.
This diff includes some ideas submited by Thor Simon to NetBSD via miod@.
ok mikeb@, haesbaert@
|
| |
|
|
| |
in fpsp has to be renamed due to a clash with other parts of the kernel.
|
| |
|
|
|
|
|
|
|
| |
right thing for whichever compiler we use.
found while trying to build a profiled kernel on sparc64. solution found
by guenther and refined by miod and kettenis.
ok guenther@ kettenis@
|
| | |
|
| |
|
|
| |
ok guenther millert kettenis
|
| |
|
|
| |
ok deraadt
|
| |
|
|
|
|
|
| |
up to 3 times slower than the C code most of the time. This was
brought up by DragonflyBSD guys initially.
ok deraadt, guenther. miod will not miss it.
|