BPF users expect to see basic block labels (e.g. <L0>, <L1>) in
disassembly output
(https://github.com/llvm/llvm-project/pull/95103#issuecomment-3771234810).
Default --symbolize-operands to on for BPF targets when neither
--symbolize-operands nor --no-symbolize-operands is explicitly
specified.
Add --no-symbolize-operands to allow users to opt out.
# Motivation
When using `dsymutil` to generate dSYM for large binaries, sometimes we
want to keep only some of the object files. This has the benefits of
reduced dSYM size and improved performance of LLDB and other tools which
consume the dSYM.
The current way to achieve this is to use YAML input (the `dsymutil -y`
option). However, it doesn't really solve the problem:
1. The whole debug map has to be parsed somewhere else first, before
filtered down to the wanted parts.
2. Said info is written then read by `dsymutil`. The I/O is redundant.
# Change
This patch propose a new way, by adding new options (`dsymutil --allow
<path>` and `--disallow <path>`), which will only process object files
that pass the allow/disallow list.
Important details:
* The input file is YAML. See test files for format.
* Currently, only object files are filtered. The design allows to extend
the filtering to other aspects of the debug map in the future (e.g.
functions).
* If `--oso-prepend-path` is specified, it applies to the entries in the
input file. I.e. Entries in the input file should exact match that of
N_OSO entries.
The range is an unsigned integer where a value of `UINT32_MAX` denotes
an unbounded range
The current implementation implied that any size interpreted as a signed
integer that is negative was unbounded, which is incorrect.
Adds a note to the docs
Currently, `DynamicLoaderPOSIXDYLD::GetThreadLocalData()` only supports
the TLS memory layout where the thread pointer register points to the
start of the `pthread` structure, and the address of the DTV pointer can
be calculated by adding the offset of the `dtv` field to `tp`. On ARM
(and AArch64), the thread pointer points directly to `dtv`. The patch
improves the detection of the actual memory layout in the method and
adjusts the calculations for the new case, thus adding support for
thread-local variables on ARM Linux.
Allow specification of the underlying C++ data type for `GenericEnum`.
I ran into this because I was trying to use a TableGen-genered enum in
`DenseSet` which requires the underlying type be specified.
Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
This PR introduces a new opt-in CMake option
`LLVM_ENABLE_WARNING_SUPPRESSIONS` (default `ON`) to toggle warning
suppressions
Previously, several compiler warnings were explicitly disabled using
`-wd` (for MSVC) or `-Wno-...` (for GCC/Clang) flags by default.
However, this causes validation failures with strict compliance scanners
like BinSkim, which require builds to run without any warning
suppressions to meet SDL compliance standards.
This change introduces an opt-in `LLVM_ENABLE_WARNING_SUPPRESSIONS`
option (default ON). When explicitly disabled (OFF), it selectively
filters out the `-wd` flags for MSVC and removes all `-Wno-...` flags
for GCC/Clang in HandleLLVMOptions.cmake. This ensures all compiler
warnings are exposed as intended for static analysis tools while
preserving the default noise-free build experience for regular users.
The option has also been exported to `LLVMConfig.cmake.in` and
documented in `CMake.rst`.
Signed-off-by: Zhu, Shaojie <shaojie.zhu@intel.com>
The current LangRef wording says that the sign of a zero argument or
result is "insignificant", which is not really clear on what this means.
Alive2 models this as non-deterministically flipping the zero sign bits
for both inputs and outputs.
This PR proposes to specify this flag as non-deterministically flipping
inputs only. A consequence of this is that fabs is guaranteed to have an
unset sign bit even if the input is zero (that is,
https://alive2.llvm.org/ce/z/irCftQ is no longer a valid transform), and
that the copysign result sign only depends on the second operand (that
is, https://alive2.llvm.org/ce/z/VnHdfh is no longer a valid transform).
These rules are still more liberal than we'd really like them to be, but
at least avoid some of the issues with nsz.
This is based on the discussion in:
https://discourse.llvm.org/t/rfc-clarify-the-behavior-of-fp-operations-on-bit-strings-with-nsz-flag/85981
This is LLDB version of
https://cgit.freebsd.org/ports/tree/devel/gdb/files/kgdb/riscv-fbsd-kern.c.
This enables selecting riscv64 and reading registers from PCB structure
on core dump and live kenrel debugging while trapframe unwinding support
will be implemented in future. Test files using core dump from riscv64
will be implemented once other kernel debugging improvements are done.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
This is LLDB version of
https://cgit.freebsd.org/ports/tree/devel/gdb/files/kgdb/ppcfbsd-kern.c.
This enables selecting ppc64le and reading registers from PCB structure
on core dump and live kernel debugging. FPU registers aren't supported
yet due to pcb structure issue, but this change still achieves feature
parity with KGDB. Trapframe unwinding support will be implemented in
future. Test files using core dump from ppc64le will be implemented once
other kernel debugging improvements are done.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
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>
Previously vscale_range used to add the constraint that vscale is a
power-of-two, but after #183080 it's already a power-of-two to begin
with.
This clarifies the sentence about assumptions when there is no attribute
The `HowToSetUpLLVMStyleRTTI.rst` document contained a TODO requesting
documentation for advanced RTTI usage, such as the `isa_impl` and
`simplify_type` templates. This patch resolves and removes that TODO by
adding the relevant usage introductions for `simplify_type`.
Since `isa_impl` will be moved to `namespace detail` in the future we
are not including it in the documentation.
CC: @nikic @zwuis
Signed-off-by: Lidong Yan <yldhome2d2@gmail.com>
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>
An alloca with a poison element count is undefined behavior.
This matches existing behavior of optimizations. This also matches the
behavior of llubui for `poison`, but llubi currently does not report
immediate UB for `undef` element counts. A future patch will fix that.
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.
This patch is a reland of #157499
Introduce a new flag --call-graph-info which outputs call graph
information in the ELF call graph section in JSON or LLVM style.
This is the second patch in the LFI series, adding the following
features:
* `MCLFIRewriter` class, which will be used to perform LFI rewrites on a
per-architecture basis. Each architecture where LFI is supported will
implement a subclass (for example,
`Target/AArch64/MCTargetDesc/AArch64MCLFIRewriter.cpp`) that will
implement the `rewriteInst` function to perform the actual rewriting
(the AArch64 version will be added in the next PR). The generic rewriter
class provides some instruction info utilities (`mayLoad`, `mayStore`)
and is used to call `rewriteInst` during instruction emission. It also
provides `onLabel` which allows the rewriter to know possible branch
targets, making certain optimizations like guard elimination possible.
* LFI streamer initialization that marks object files with a NOTE
section to indicate that the object file is using LFI.
* A basic LFI assembly parser that introduces the `.lfi_rewrite_disable`
and `.lfi_rewrite_enable` directives that can be used to control whether
rewriting is enabled or not in hand-written assembly.
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>
As far as I can tell there are 2 parallel plugin mechanisms.
opt -load=plugin does not work, and is ignored. opt -load-pass-plugin
does work. PluginLoader.h forces a static definition of the "load"
cl::opt into included TUs. Delete the cases with no tests.
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.
- Refactor register operand parsing to eliminate duplicated LLT parsing
code.
- Additionally, fix the register operand syntax in MI LangRef to match
what the parser supports.
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).
