[ASan] [Windows] Fix a new test in mingw mode
The new test case added in 781719778003ca298ca57e486ab629b7f384844b
didn't work in mingw mode; defines set through `/D` only works when
using the clang-cl compiler driver, not the regular clang compiler
driver.
Switch this to use `-D`, which works with both plain clang and
clang-cl, so we don't need to use a lit macro for expanding
the right option to use.
[lldb] Add extended variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_extended_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include extended variables or not and leave comments explaining the decision.
As a consequence of producing extended variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no extended variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[ELF] Add target-specific relocation scanning for PPC64 (#181496)
Implement PPC64::scanSectionImpl, following the pattern established for
x86. This merges the getRelExpr and TLS handling for SHF_ALLOC sections
into the target-specific scanner, enabling devirtualization and
eliminating abstraction overhead.
- Inline relocation classification into scanSectionImpl with a switch
on relocation type, replacing the generic rs.scan() path.
- Use processR_PC/processR_PLT_PC for common PC-relative and PLT
relocations.
- Handle TLS GD, LD, and DTPREL directly, eliminating
handleTlsRelocation, getTlsGdRelaxSkip, and adjustTlsExpr overrides.
Use handleTlsIe for TLS IE, enabling IE-to-LE optimization even when
ppc64DisableTLSRelax is set (lifted a limitation from
the workaround patch https://reviews.llvm.org/D92959).
- Use processAux for R_PPC64_PCREL_OPT. Remove the PPC64-specific
special case from process().
- Replace RE_PPC64_RELAX_GOT_PC with R_RELAX_GOT_PC, which computes
[5 lines not shown]
[LV] Add argmin test for epilogue vectorization w/o wide canonical IV.
Add additional epilogue vectorization test coverage for
https://github.com/llvm/llvm-project/pull/170223.
Also regenerate check lines for related tests.
[lldb] Add extended variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_extended_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include extended variables or not and leave comments explaining the decision.
As a consequence of producing extended variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no extended variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[lldb] Scaffolding for extended variable support.
This patch handles most of the scaffolding for extended variable support that isn't directly tied to functional changes. This patch will be used by one following patch that actually modifies the lldb_private::StackFrame API to allow us to fetch extended variables.
There were a couple important/interesting decisions made in this patch that should be noted:
- Any value type may be 'extended', which is why it's a mask applied over the top of another value type.
- When printing frame variables with `fr v`, default to showing extended variables.
This new value type mask makes some of the ValueType handling more interesting, but since nothing generates objects with this mask until the next patch, we can land the concept in this patch in some amount of isolation.
stack-info: PR: https://github.com/llvm/llvm-project/pull/181500, branch: users/bzcheeseman/stack/8
[lldb] NFC: Use standard comment for lldb-python.h include (#181498)
## Summary
Use the standard `// LLDB Python header must be included first.` comment
to match every other Python interface `.cpp` file in this directory, as
suggested by @JDevlieghere.
## Test plan
NFC - comment only change.
Co-authored-by: Rahul Reddy Chamala <rachamal at meta.com>
[Github][libc] Also build arm container (#181497)
Some of the libc full build tests also run on AArch64 machines. We need
to build an ARM container or otherwise the container fails to start and
we never end up running anything.
[lldb] Fix Windows linker error for MakeSBModuleSpec in lldb-server (#181494)
## Summary
Move the definition of `ScriptInterpreter::MakeSBModuleSpec` from
`ScriptInterpreter.cpp` to `ScriptedPythonInterface.cpp`.
`MakeSBModuleSpec` constructs an `SBModuleSpec`, whose symbols live in
the API library (`liblldb`). `ScriptInterpreter.cpp` is part of
`lldbInterpreter`, which is also linked into `lldb-server` — and
`lldb-server` does not link the API library. On Windows, this causes
`LNK2019: unresolved external symbol` for `SBModuleSpec`'s constructor
and destructor.
`ScriptedPythonInterface.cpp` is part of the Python plugin library,
which only links into `liblldb` where the API symbols are available. The
method retains friend access to `SBModuleSpec` since it is still a
member of `ScriptInterpreter` regardless of which `.cpp` file defines
it.
[5 lines not shown]
[lldb] Fix pid_t redefinition on Windows in ScriptInterpreterPythonInterfaces (#181493)
## Summary
Include `lldb-python.h` as the first include inside the
`LLDB_ENABLE_PYTHON` block in `ScriptInterpreterPythonInterfaces.cpp`,
matching the pattern used by every other Python interface `.cpp` file in
this directory.
On Windows, `lldb-python.h` defines `NO_PID_T` before including
`Python.h`. This prevents `PosixApi.h` (transitively included via
`lldb-private.h`) from redefining `pid_t` with a conflicting type
(`uint32_t` vs `int`).
The issue was introduced by #181334 (ScriptedSymbolLocator plugin),
which added a new header whose include chain transitively reaches
`PosixApi.h`.
Fixes Windows build failures on lldb-aarch64-windows, lldb-x86_64-win,
and lldb-remote-linux-win.
[6 lines not shown]
[lldb] Fix pid_t redefinition on Windows in ScriptInterpreterPythonInterfaces (#181492)
## Summary
- Move `#include "lldb/Core/PluginManager.h"` after `#include
"ScriptInterpreterPythonInterfaces.h"` so Python's `pyconfig.h` defines
`pid_t` before `PosixApi.h` gets included. This fixes the `C2371:
'pid_t': redefinition; different basic types` error on all Windows
builders.
Fixes CI failures from #181334 / #181488.
Co-authored-by: Rahul Reddy Chamala <rachamal at meta.com>
[lldb] Fix Windows build and remote test failure for ScriptedSymbolLocator (#181488)
## Summary
- Move `GetScriptedSymbolLocatorClassName()` from inline in `Target.h`
to out-of-line in `Target.cpp` to avoid collision with Windows
`winuser.h` `#define GetClassName GetClassNameW` macro.
- Replace `LaunchSimple(None, None, os.getcwd())` with
`lldbutil.run_to_breakpoint_do_run()` in `test_locate_source_file` to
fix test failure on remote platforms where the local working directory
doesn't exist.
Fixes CI failures from #181334.
## Test plan
- [ ] Windows (aarch64-windows) build passes
- [ ] remote-linux-win test passes
- [ ] Existing ScriptedSymbolLocator tests pass on local platforms
Co-authored-by: Rahul Reddy Chamala <rachamal at meta.com>
[lldb] Add ScriptedSymbolLocator plugin for source file resolution (#181334)
## Summary
Based on discussion from
[RFC](https://discourse.llvm.org/t/rfc-python-callback-for-source-file-resolution/83545),
this PR adds a new `SymbolLocatorScripted` plugin that allows Python
scripts to implement custom symbol and source file resolution logic.
This enables downstream users to build custom symbol servers, source
file remapping, and build artifact resolution entirely in Python.
### Changes
- Adds `LocateSourceFile()` to the SymbolLocator plugin interface,
called during source path resolution with a fully loaded `ModuleSP`, so
the plugin has access to the module's UUID, file paths, and symbols.
- Adds `SymbolLocatorScripted` plugin that delegates all four
SymbolLocator methods (`LocateExecutableObjectFile`,
`LocateExecutableSymbolFile`, `DownloadObjectAndSymbolFile`,
[34 lines not shown]
[DAGCombiner] Fix crash caused by illegal InterVT in ForwardStoreValueToDirectLoad (#181175)
This patch fixes an assertion failure in ForwardStoreValueToDirectLoad
during DAGCombine.
The crash occurs when `STLF (Store-to-Load Forwarding)` creates an
illegal intermediate bitcast type (e.g., `v128i1` when bridging a
128-bit store to a `<32 x i1>` load on X86). Since `v128i1` is not a
legal mask type for the backend, it violates the expectations of the
LegalizeDAG pass.
The fix adds a `TLI.isTypeLegal(InterVT)` check to ensure that the
intermediate type used for the transformation is supported by the
target.
Fixes #181130
[Clang][inlineasm] Add special support for "rm" output constraints (#92040)
Clang isn't able to support multiple constraints on inputs and outputs,
like "rm". Instead, it picks the "safest" one to use, i.e. the memory
constraint for "rm". This leads to obviously horrible code:
asm __volatile__ ("pushf\n\t"
"popq %0"
: "=rm" (x));
is compiled to:
pushf
popq -8(%rsp)
movq -8(%rsp), %rax
It gets worse when inlined into other functions, because it may
introduce
a stack where none is needed.
[16 lines not shown]
[libc++] Refactor std::push_heap benchmark (#181343)
We're trying to get the time it takes to run all the benchmarks down, so
that we can run them on a regular basis. This patch saves us ~8 minutes
per run.
Fixes #177028
Reapply "[msan] Switch switch() from strict handling to (icmp eq)-style handling" (#180636) (#181112)
This reverts https://github.com/llvm/llvm-project/pull/180636 i.e.,
relands https://github.com/llvm/llvm-project/pull/179851.
It was originally reverted because of buildbot failures. When compiling
switch statements with many cases (e.g., AMDGPUGenMCCodeEmitter.inc has
>30,000 cases), MSan's instrumentation created an extremely long chained
expression for the shadow computation. Although that was legal LLVM IR,
it caused the subsequent JumpThreadingPass to have a stack overflow.
This reland avoids the issue by limiting the number of cases considered
(`-msan-switch-precision`), with the tradeoff of niche false negatives
(only in the case where the condition is partly uninitialized and the
first x cases still have a defined comparison, but a case # > x does not
have a fully-defined comparison).
This reland also adds some TODOs for possible improvements.
[39 lines not shown]
[ELF] Move RISCV scanSectionImpl next to getRelExpr. NFC
Move scanSectionImpl and scanSection to right after getRelExpr and
before relocate, matching the ordering used in X86_64.cpp and PPC64.cpp.
