| Age | Commit message (Collapse) | Author |
|---|
|
This is very likely full of wrong stuff. It's effectively just a copy of the
mips64 file - needed because the former stopped using usize/isize. To be clear,
this is no more broken than the old situation was; this just makes the
brokenness explicit.
|
|
|
|
arch bits
Flock is now equivalent to struct flock64, and the related F.* constants map to
the 64-bit variants on 32-bit systems.
|
|
|
|
|
|
|
|
|
|
I'm not particularly happy with sprinkling this check everywhere, but the
situation should improve once we complete the time64 migration.
|
|
|
|
`std.debug`: implement `sparc*-linux` unwinding
|
|
This is a rewrite of the BLAKE3 implementation, with vectorization.
On Apple Silicon, the new implementation is about twice as fast as the previous one.
With AVX2, it is more than 4 times faster.
With AVX512, it is more than 7.5x faster than the previous implementation (from 678 MB/s to 5086 MB/s).
|
|
The way SPARC works due to its ABI built around register windows means that we
can always do fast FP-based unwinding.
|
|
The return address points to the call instruction on SPARC, so the actual return
address is 8 bytes after. This means that we shouldn't do the return address
adjustment that we normally do.
|
|
The FP would point to the register save area for the previous frame, while the
SP points to the register save area for the current frame. So use the latter.
|
|
I have no idea if this is a QEMU bug or real kernel behavior. Either way, the
register save area specifically exists for asynchronous spilling of incoming and
local registers, so there should be no harm in doing this.
|
|
|
|
|
|
We're overwriting the memory that unwind_context sits in, so we need to do the
getFp() call earlier.
|
|
|
|
It's not really a ucontext_t at all. Lovely stuff.
|
|
It's better to do this here than in StackIterator.init() so that
std.debug.cpu_context.Native.current() isn't a footgun on SPARC.
|
|
|
|
flushw and ta 3 flush all windows *except* the current one. So we need to do
this in a new register window to get all of the ones we care about.
|
|
As for SPARC, FP-based unwinding is superior on these.
|
|
|
|
`libcxx`: backport llvm/llvm-project#155476, llvm/llvm-project#147389, llvm/llvm-project#155786
|
|
https://github.com/llvm/llvm-project/pull/152942
|
|
LLVM currently doesn't recognize xcc; icc does what we want.
|
|
https://github.com/llvm/llvm-project/pull/155786
|
|
https://github.com/llvm/llvm-project/pull/147389
|
|
https://github.com/llvm/llvm-project/pull/155476
|
|
* std.crypto: add AES-CCM and CBC-MAC
Add AES-CCM (Counter with CBC-MAC) authenticated encryption and
CBC-MAC message authentication code implementations to the standard
library.
AES-CCM combines CTR mode encryption with CBC-MAC authentication as
specified in NIST SP 800-38C and RFC 3610. It provides authenticated
encryption with support for additional authenticated data (AAD).
CBC-MAC is a simple MAC construction used internally by CCM, specified
in FIPS 113 and ISO/IEC 9797-1.
Includes comprehensive test vectors from RFC 3610 and NIST SP 800-38C.
* std.crypto: add CCM* (encryption-only) support to AES-CCM
Implements CCM* mode per IEEE 802.15.4 specification, extending
AES-CCM to support encryption-only mode when tag_len=0. This is
required by protocols like ZigBee, Thread, and WirelessHART.
Changes:
- Allow tag_len=0 for encryption-only mode (no authentication)
- Skip CBC-MAC computation when tag_len=0 in encrypt/decrypt
- Correctly encode M'=0 in B0 block for CCM* mode
- Add Aes128Ccm0 and Aes256Ccm0 convenience instances
- Add IEEE 802.15.4 test vectors and CCM* tests
* std.crypto: add doc comments for AES-CCM variants
|
|
unsupported
If these ever get allocated, it's most likely going to be for things that don't
matter to us anyway, so completely abandoning DWARF unwinding just because we
see these doesn't seem justified. We will still do so if we're actually asked to
read from such a register, which is the only actually problematic case; see
c23a5ccd19 for more details.
|
|
https://www.openwall.com/lists/musl/2025/10/12/4
See also 7b92d5f4052be651e9bc5cd4ad78a69ccbee865d...
|
|
|
|
This is to help diagnose #25498. We can't use `unexpectedErrno` here,
because `std.posix.munmap` is infallible. So, when the flag is set to
report unexpected errnos, we just call `std.debug.panic` to provide
details instead of doing `unreachable`.
Pushing straight to master after running checks locally; there's no
point waiting for CI on the PR just for this.
|
|
|
|
This was causing flaky CI failures.
|
|
Add error bundle support to `translate-c`, unify `cmdTranslateC` and `cImport`
|
|
|
|
This same change was applied in 69007f096177143086e28da0dc1a0eff4efcc52c but accidentally reverted in 7bf740ee718f4b6109cd9fe7014d1784d48ada48
|
|
This fixes leaf function unwinding, presumably among other things.
|
|
`std.debug`: greatly expand target support for segfault handling/unwinding, and remove public `ucontext_t` completely
|
|
This type is useful for two things:
* Doing non-local control flow with ucontext.h functions.
* Inspecting machine state in a signal handler.
The first use case is not one we support; we no longer expose bindings to those
functions in the standard library. They're also deprecated in POSIX and, as a
result, not available in musl.
The second use case is valid, but is very poorly served by the standard library.
As evidenced by my changes to std.debug.cpu_context.signal_context_t, users will
be better served rolling their own ucontext_t and especially mcontext_t types
which fit their specific situation. Further, these types tend to evolve
frequently as architectures evolve, and the standard library has not done a good
job keeping up, or even providing them for all supported targets.
|
|
I made a couple of decisions for this based on the fact that we don't expose the
signal_ucontext_t type outside of the file:
* Adding all the floating point and vector state to every ucontext_t and
mcontext_t variant was way, way too much work, especially when we don't even
use the stuff. So I deleted all that and kept only the bare minimum needed to
reach into general-purpose registers.
* There is no particularly compelling reason to stick to the naming and struct
nesting used in the system headers. So we can actually unify the access
patterns for almost all of these variants by taking some liberties here; as a
result, fromPosixSignalContext() is now much nicer to read and extend.
|
|
|
|
|
|
|
|
|
|
|
