LLDB automatically discovers, but doesn't automatically load, scripts in
the dSYM bundle. This is to prevent running untrusted code. Users can
choose to import the script manually or toggle a global setting to
override this policy. This isn't a great user experience: the former
quickly becomes tedious and the latter leads to decreased security.
This PR offers a middle ground that allows LLDB to automatically load
scripts from trusted dSYM bundles. Trusted here means that the bundle
was signed with a certificate trusted by the system. This can be a
locally created certificate (but not an ad-hoc certificate) or a
certificate from a trusted vendor.
And highlights that some earlier versions have a critical issue on such
systems. This is not something we are able to fix (because the branches
are closed), but users and packagers have some options which are listed
in the issue.
Relates to #138717.
In LTO, part of LLVM's middle-end runs after linking has finished. LTO's
semantics depend on the complete set of extracted bitcode files being
known at this time. If the middle-end inserts new calls to library
functions (libfuncs) that are implemented in bitcode, this could extract
new bitcode object files into the link. These cannot be compiled,
leading to undefined symbol references.
Additionally, the middle-end in LTO may reason that such library
functions have no references, and it may internalize them, then
manipulate their API or even delete them. Afterwards, it may emit a call
to them, again producing undefined symbol references.
This patch resolves the former issue by ensuring that the middle end
emits no new references to symbols defined in bitcode, and it resolves
the latter issue by ensuring that extracted bitcode for libfuncs is
considered external, since new calls may be emitted to them at any time.
The new semantics are not yet established for MachO LLD, which does not
yet appear to have any special handling for libcalls in LTO. It also
does not yet support distributed ThinLTO; doing so would require
additional (de)serialization work.
This is the patch referenced in @ilovepi's and my talk at the last LLVM
devmeeting: "LT-Uh-Oh"
Gemini 3.1 was used in porting to COFF and WASM LLDs.
Add a new PlatformWebInspectorWasm, which is a Wasm platform that
automatically connects to the WebInspector platform server.
The existing "wasm" platform handles WebAssembly generally and allows
you to configure a runtime to launch under. The "webinspector-wasm"
platform does the inverse, and only supports attaching to an already
running WebAssembly instance in Safari. The workflow here is always
`platform process list` followed by `platform process attach`. This
explains why you can only force create this platform and it's never
automatically selected when loading a Wasm target.
The encoded immediate is the number of trailing 1s in the maximum value.
Mailing list discussion has a preference to print and parse this value
plus one. https://lists.riscv.org/g/tech-p-ext/message/910
With this patch, saturating to a signed 8-bit integer would be "sati a0,
a0, 8". Previously it was "sati a0, a0, 7".
This is reflected in version 0.20 of the adoc spec here
https://github.com/riscv/riscv-p-spec/pull/226. I have updated our
RISCVUsage.rst to point to the adoc version of the spec.
This adds a portable `readlink` function, and adds `create_symlink` to
enable testing this on Windows. `create_link` previously created a hard
link on Windows, but it now tries to create a symlink first.
The Windows implementation is based on posix_compat.h from libc++.
Assisted-by: claude-opus-4.6
This patch adds a Clang-compatible -mtune option to llc, to enable
decoupled ISA and microarchitecture targeting, which is especially
important for backend development. For example, it can enable to easily
test a subtarget feature or scheduling model effects on codegen across a
variaty of workloads on the IR corpus benchmark:
https://github.com/dtcxzyw/llvm-codegen-benchmark.
The implementation adds an isolated generic codegen flag, to establish a
base for wider usage - the plan is to add it to `opt` as well in a
followup patch. Then `llc` consumes it, and sets `tune-cpu` attributes
for functions, which are further consumed by the backend.
I found this occasionally.
For outer let statements, if we want to override some bits, we specify
the range list in the form of `<n-m>`. But for inner let statements,
we use `{n-m}`.
This is inconsistent, and I can't find the reason why it is designed
as this. So here we make inner/outer let statements consistent and
remove the duplicated parsing functions.
There is only one in-tree usage so I think the impact is small.
BranchInst currently represents both unconditional and conditional
branches. However, these are quite different operations that are often
handled separately. Therefore, split them into separate opcodes and
classes to allow distinguishing these operations in the type system.
Additionally, this also slightly improves compile-time performance.
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.
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>
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.
