Implement `ProcessFreeBSDKernelCore::DoWriteMemory()` to write data on
kernel crash dump or `/dev/mem`. Due to safety reasons (e.g. writing
wrong value on `/dev/mem` can trigger kernel panic), this feature is
only enabled when `plugin.process.freebsd-kernel-core.read-only` is set
to false (true by default).
Since 85a1fe6 (#183237) was reverted as it was prematurely merged, I'm
committing changes again with corrections here.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
XuanTie C910V2 and C920V2 are 64-bit superscalar out-of-order CPUs:
https://www.xrvm.com/community/download?id=4530178488929423360
C910V2 is a C920V2 version without vector, zvfbfmin, zvfbfwma, zvfh and
xtheadvdot extensions.
Scheduling model will be added in a further PR.
Implement `ProcessFreeBSDKernelCore::DoWriteMemory()` to write data on
kernel dump or `/dev/mem`. Due to security concerns (e.g. writing wrong
value on `/dev/mem` can trigger kernel panic), this feature is only
enabled when `plugin.process.freebsd-kernel-core.read-only` is set to
false (true by default).
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
All known crashes have been fixed.
We do still need to work out how fixed length vectors are handled when V
and P are both enabled, but I don't think this option is the solution
for that.
This is LLDB version of
https://cgit.freebsd.org/ports/tree/devel/gdb/files/kgdb/arm-fbsd-kern.c.
This enables selecting arm and reading registers from PCB structure on
core dump and live kernel debugging while trapframe unwinding support
will be implemented in future. Test files using core dump from arm will
be implemented once other kernel debugging improvements are done.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
For crash reduction, I don't think it does anything that llvm-reduce
can't. Pass pipeline reduction also has a separate reduction script.
The main thing there isn't a replacement tool is the miscompilation
reducer, but I'm not sure that's actually functioned for years.
There are still some references to bugpoint in various comments
and pieces of documentation that don't all necessarily make sense
to replace or remove. In particular there are a few passes documented
as "only for bugpoint", but I've left those alone in case they are
useful for manual reductions.
There are two different ways to debug FreeBSD's kernel: core and remote
debugging. Remote debugging is done through `gdb-remote` plugin while
kernel dump and live core debugging is done through `freebsd-kernel`.
The name `freebsd-kernel` is vague for this reason, and following
`elf-core` and `mach-core`'s example, it would be clearer if this plugin
is renamed to `freebsd-kernel-core`.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
This implements reading the TPIDRURO register, which serves as the
thread pointer register on ARM Linux. Note that the register is not
displayed for core files because it is not included in the dump.
Due to libfbsdvmcore, adding new features requires modifying both
`ProcessFreeBSDKernelFVC` and `ProcessFreeBSDKernelKVM` which also
requires testing on both. This is highly inefficient while the user base
of fvc is currently invisible since most package manager don't ship
libfbsdvmcore with LLDB.
There is still demand for cross-platform kernel dump debugging. This
will be implemented in future either by cloning and embedding kvm
interface into LLDB or unifying dump formats to ELF core with
minidump-to-elf conversion tool on FreeBSD side.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Remove `+d128` gating on `sysp`, `msrr` and `mrrs` instructions.
We removed gating for `sys`, `mrs` and `mrs` instructions previously,
on the basis that it doesn't add value, as it doesn't indicate that
any particular system registers or system instructions are available.
Therefore, remove `+d128` gating for these instructions too.
(In upcoming change #178913, some `tlbip` instructions, which are `sysp`
aliases are allowed to be used with either `+d128` or `tlbid`. If we don't
remove this gating, then it would require some ugly work-arounds in the
code to support the relaxation mandated by the 2025 MemSys specification.
In this change, retain `+d128` gating for all `tlbip` instructions, which
will then be loosened to either `+d128` or `+tlbid` in a subsequent
change)
This was originally introduced to support kalimba DSPs featuring 24-bit
bytes by f03e6d84 and also c928de3e, but the kalimba support was mostly
removed by f8819bd5. This change removes the rest of the support, which
was far from complete.
This commit introduces an "adaptive delay" feature to the
ThreadSanitizer runtime to improve race detection by perturbing thread
schedules. At various synchronization points (atomic operations,
mutexes, and thread lifecycle events), the runtime may inject small
delays (spin loops, yields, or sleeps) to explore different thread
interleavings and expose data races that would otherwise occur only in
rare execution orders.
This change is inspired by prior work, which is discussed in more detail
on
https://discourse.llvm.org/t/rfc-tsan-implementing-a-fuzz-scheduler-for-tsan/80969.
In short, https://reviews.llvm.org/D65383 was an earlier unmerged
attempt at adding a random delays. Feedback on the RFC led to the
version in this commit, aiming to limit the amount of delay.
The adaptive delay feature uses a configurable time budget and tiered
sampling strategy to balance race exposure against performance impact.
It prioritizes high-value synchronization points with clear
happens-before relationships: relaxed atomics receive lightweight spin
delays with low sampling, synchronizing atomics (acquire / release /
seq_cst) receive moderate delays with higher sampling, and mutex and
thread lifecycle operations receive the longest delays with highest
sampling.
The feature is disabled by default and incurs minimal overhead when not
enabled. Nearly all checks are guarded by an inline check on a global
variable that is only set when enable_adaptive_delay=1. Microbenchmarks
with tight loops of atomic operations showed no meaningful performance
difference between an unmodified TSAN runtime and this version when
running with empty TSAN_OPTIONS.
An LLM assisted in writing portions of the adaptive delay logic,
including the TimeBudget class, tiering concept, address sampler, and
per-thread quota system. I reviewed the output and made amendments to
reduce duplication and simplify the behavior. I also replaced the LLM's
original double-based calculation logic with the integer-based Percent
class. The LLM also helped write unit test cases for Percent.
cc @dvyukov
## Examples
I used the delay scheduler to find novel bugs that rarely or never
occurred with the unmodified TSAN runtime. Some of the bugs below were
found with earlier versions of the delay scheduler that I iterated on,
but with this most recent implementation in this PR, I can still find
the bugs far more reliably than with the standard TSAN runtime.
- A use-after-free in the
[BlazingMQ](https://github.com/bloomberg/blazingmq) broker during
ungraceful producer disconnect.
- Race in stdexec: https://github.com/NVIDIA/stdexec/pull/1395
- Race in stdexec's MPSC queue:
https://github.com/NVIDIA/stdexec/pull/1812
- A few races in [BDE](https://github.com/bloomberg/bde) thread enabled
data structures/algorithms.
- The "Data race on variable a" test from
https://ceur-ws.org/Vol-2344/paper9.pdf is more reliably reproduced with
more aggressive adaptive scheduler options
# Outstanding work
- The
[RFC](https://discourse.llvm.org/t/rfc-tsan-implementing-a-fuzz-scheduler-for-tsan/80969)
suggests moving the scheduler to sanitizer_common, so that ASAN can
leverage this. This should be done (should it be done in this PR?).
- Missing interceptors for libdispatch
`Constant::isZeroValue` currently behaves same as
`Constant::isNullValue` for all types except floating-point, where it
additionally returns true for negative zero (`-0.0`). However, in
practice, almost all callers operate on integer/pointer types where the
two are equivalent, and the few FP-relevant callers have no meaningful
dependence on the `-0.0` behavior.
This PR removes `isZeroValue` to eliminate the confusing API. All
callers are changed to `isNullValue` with no test failures.
`isZeroValue` will be reintroduced in a future change with clearer
semantics: when null pointers may have non-zero bit patterns,
`isZeroValue` will check for bitwise-all-zeros, while `isNullValue` will
check for the semantic null (which
may be non-zero).
Since there will be many changes to LLDB on FreeBSD support in 23,
create subheaders for FreeBSD to separate related changes into relevant
subheaders.
This also adds #178069 and #178306 in the release note.
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
This change turns the `"nooutline"` attribute into an enum attribute
called `nooutline`, and adds an auto-upgrader for bitcode to make the
same change to existing IR.
This IR attribute disables both the Machine Outliner (enabled at Oz for
some targets), and the IR Outliner (disabled by default).
Currently versions under 13 are EOLed (see [FreeBSD Release
Information](https://www.freebsd.org/releases/)).
FreeBSD 13 will be EOLed by April 30th (see [Supported FreeBSD
releases](https://www.freebsd.org/security/#sup)) while LLVM 23 is
expected to be released in August 25th according to the LLVM calendar.
Thus assumed that minimum supported FreeBSD version is 14.
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
The last FreeBSD version supporting mips64 is FreeBSD 13 which will be
EOLed on April 30th. LLVM 23.1.0 release is expected to be August 25th
according to the LLVM calendar. The usage of mips64 is less noticeable
so it's hard to know if it is properly working, and even if it works, it
is hard to test new features on FreeBSD mips64.
Thus, remove support for mips64 on FreeBSD.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Convert "denormal-fp-math" and "denormal-fp-math-f32" into a first
class denormal_fpenv attribute. Previously the query for the effective
denormal mode involved two string attribute queries with parsing. I'm
introducing more uses of this, so it makes sense to convert this
to a more efficient encoding. The old representation was also awkward
since it was split across two separate attributes. The new encoding
just stores the default and float modes as bitfields, largely avoiding
the need to consider if the other mode is set.
The syntax in the common cases looks like this:
`denormal_fpenv(preservesign,preservesign)`
`denormal_fpenv(float: preservesign,preservesign)`
`denormal_fpenv(dynamic,dynamic float: preservesign,preservesign)`
I wasn't sure about reusing the float type name instead of adding a
new keyword. It's parsed as a type but only accepts float. I'm also
debating switching the name to subnormal to match the current
preferred IEEE terminology (also used by nofpclass and other
contexts).
This has a behavior change when using the command flag debug
options to set the denormal mode. The behavior of the flag
ignored functions with an explicit attribute set, per
the default and f32 version. Now that these are one attribute,
the flag logic can't distinguish which of the two components
were explicitly set on the function. Only one test appeared to
rely on this behavior, so I just avoided using the flags in it.
This also does not perform all the code cleanups this enables.
In particular the attributor handling could be cleaned up.
I also guessed at how to support this in MLIR. I followed
MemoryEffects as a reference; it appears bitfields are expanded
into arguments to attributes, so the representation there is
a bit uglier with the 2 2-element fields flattened into 4 arguments.
Per the psABI discussion in riscv-non-isa/riscv-elf-psabi-doc#474, the
conclusion was to NOT introduce a new build attribute for MOP/HINT
encoding reinterpretation. Instead, the toolchain should recognize these
mnemonics unconditionally in the assembler and disassembler.
The rationale is that these encodings occupy reserved hint/MOP space
that is architecturally guaranteed not to trap on any compliant
implementation. Requiring explicit extension flags creates unnecessary
friction for users who simply want to write or read these instructions,
while providing no real safety benefit since the encodings are always
valid.
Note: Ideally, the ISA specification would explicitly guarantee that
these MOP/HINT encodings will never be reassigned to conflicting
instructions. However, the ISA architects prefer to preserve flexibility
in this area rather than making such guarantees in the spec. Given the
practical reality that reassignment is highly unlikely, the toolchain
takes the pragmatic approach of always recognizing these mnemonics.
This change makes the following mnemonics always available:
- lpad (Zicfilp): AUIPC hint encoding, always valid
- pause (Zihintpause): FENCE hint encoding, always valid
- ntl.* (Zihintntl): ADD hint encoding, always valid
- c.ntl.* (Zihintntl+C): requires C extension only
- sspush/sspopchk/ssrdp (Zicfiss): requires Zimop only (MOP encoding)
- c.sspush/c.sspopchk (Zicfiss+Zcmop): requires Zcmop only
Note: ssamoswap.w/d still requires Zicfiss as they use AMO encoding
space rather than MOP encoding.
Codegen patterns remain unchanged in this patch - generating these
instructions in the compiler backend still requires the full extension
to be enabled. A follow-up patch will relax this restriction as well,
since these instructions are fundamentally MOP/HINT encodings that
should be safe to generate regardless of extension availability.
Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/474
There was no real benefit to disallowing this, and it sometimes caused
unnecessary churn in the RUN lines of tests which were updated from
single-to-multiple or multiple-to-single prefixes.
This effectively makes -check-prefixes the primary option and
-check-prefix just an alias of it. The documentation is upated
accordingly.
This adds support for `--symbolize-operands`, so that local references
are turned back into labels by objdump, which makes it easier to tell
what is going on with a linked object.
When using `--symbolize-operands`, branch target addresses are not
printed, only the referenced symbol is printed, and the address is
elided:
```
# Without --symbolize-operands
0: 04a05263 blez a0, 0x44 <.text+0x44>
...
40: fd1ff06f j 0x10 <.text+0x10>
44: 00000613 li a2, 0x0
# With --symbolize-operands
0: 04a05263 blez a0, <L3>
...
40: fd1ff06f j <L0>
<L3>:
44: 00000613 li a2, 0x0
```
This eases interoperability by making it explicit in emitted assembly code which syntax is used.
Refactored to remove X86-specific directives and logic from the generic MC(Asm)Streamer.
Motivated by building LLVM with `-mllvm -x86-asm-syntax=intel` (i.e. a global preference for Intel
syntax). A Bolt test (`runtime/X86/fdata-escape-chars.ll`) was using `llc` to compile to assembly
and then assembling with `clang`. The specific option causes Clang to assume Intel syntax but only
for assembly and not inline assembly.
These are long overdue for removal. These were originally a hack
to support loading half values before there was any / decent support
for the half type through the backend. There's no reason to continue
supporting these, they're equivalent to fpext/fptrunc with a bitcast.
SelectionDAG stopped translating these directly, and used the
bitcast + fp cast since f7a02c17628e825, so there's been no reason
to use these since 2014.
LLVM's existing support for chaining x64 Windows SEH frame infos is
broken. Windows requires that each frame info (including the parent) is
adjacent, but not overlapping, and the whole function is covered (i.e.,
each instruction maps to exactly one frame info). Therefore, having
start/end chaining pseudo instructions doesn't make any sense, as every
"end chain" pseudo would need a start pseudo immediately after it or be
at the end of function.
This change switches having a "split chain" pseudo instruction that ends
the current frame and starts a new chained frame.
Added a release note about the replacement - to my knowledge there is no
one actually using frame info chaining, so it is highly unlikely that it
will break any code.
Split off from #159206
We already had a few MSVC STL formatters at the last release, but we
postponed the release note entry until they support PDB. The formatters
now support PDB.
There are still some left (see
https://github.com/llvm/llvm-project/issues/24834#issuecomment-3049291996),
but the most common types are formatted.
This adds code to recognize "wasm32-wasip1", "wasm32-wasip2", and
"wasm32-wasip3" as explicit targets, and adds a deprecation warning when
the "wasm32-wasi" target is used, pointing users to the "wasm32-wasip1"
target.
Fixes#165344.
I'm filing this as a draft PR for now, as I've only just now proposed to
make this change in #165344.
This new function is the same as LLVMParseIRInContext except it doesn't
take ownership of the memory buffer. This fixes a wart that has been in
place since 5ebb7b311223bcd21d2b3d25413d1edacefcc63d changed the
underlying internal API to avoid taking ownership.
Reduce nesting in the implementation of LLVMParseIRInContext (now
LLVMParseIRInContext2) as well.
Update examples, OCaml bindings, and tests including plugging some
pre-existing memory leaks. OCaml bindings have renamed `parse_ir` to
`parse_ir_bitcode_or_assembly` to provoke compilation failures in
downstream code; this is intentional as this function now requires the
memory buffer to be disposed by the caller.
On PowerPC targets, `half` uses the default legalization of promoting to
a `f32`. However, this has some fundamental issues related to inability
to round trip. Resolve this by switching to the soft legalization, which
passes `f16` as an `i16`.
The PowerPC ABI Specification does not define a `_Float16` type, so the
calling convention changes are acceptable.
Fixes the PowerPC part of
https://github.com/llvm/llvm-project/issues/97975
Fixes the PowerPC part of
https://github.com/llvm/llvm-project/issues/97981
The default `half` legalization, which Wasm currently uses, does not
respect IEEE conventions: for example, casting to bits may invoke a lossy
libcall, meaning soft float operations cannot be correctly implemented.
Change to the soft promotion legalization which passes `f16` as an `i16`
and treats each `half` operation as an individual
f16->f32->libcall->f32->f16 sequence.
Of note in the test updates are that `from_bits` and `to_bits` are now
libcall-free, and that chained operations now round back to `f16` after
each step.
Fixes the wasm portion of
https://github.com/llvm/llvm-project/issues/97981
Fixes the wasm portion of
https://github.com/llvm/llvm-project/issues/97975
Fixes: https://github.com/llvm/llvm-project/issues/96437
Fixes: https://github.com/llvm/llvm-project/issues/96438
Version 0.13 of the Xqci Qualcomm uC Vendor Extension has been marked as
frozen. We've had assembler support for this since LLVM20 and code
generation support since LLVM21. I think we have enough coverage in the
code base to mark the extension as non-experimental.
Reland #165661 with fix for memory leak.
The call to `DummyTarget->createMCSubtargetInfo` within `mcpuHelp()`
returns a pointer that is not subsequently freed, leading to a memory
leak. Use `std::unique_ptr` to ensure the memory is released
automatically.
Original description:
---
Currently --mcpu=help and --mattr=help only produce help out when
disassembling. This patch specialises these cases to always print the
requested help.
If --triple is specified, the help text will be derived from the
specified target. Otherwise, it will be derived from the target of the
first input file.
Fixes: https://github.com/llvm/llvm-project/issues/150567
Currently `--mcpu=help` and `--mattr=help` only produce help out when
disassembling. This patch specialises these cases to always print the
requested help.
If `--triple` is specified, the help text will be derived from the
specified target. Otherwise, it will be derived from the target of the
first input file.
Fixes: #150567
---------
Signed-off-by: Ruoyu Qiu <cabbaken@outlook.com>
Co-authored-by: James Henderson <James.Henderson@sony.com>
