| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The dynamic library must be transferred to the server; otherwise, the
test will fail because the inferior process will not launch.
|
|
This patch replaces the usages of `$(RM)` with cross platform `$(call
RM,...)` calls which was added in
https://github.com/llvm/llvm-project/pull/180224.
|
|
This test was failing locally for me because I command script import
statements in my `~/.lldibinit` which print to `stdout`. E.g.,:
```
Traceback (most recent call last):
File "/Users/michaelbuch/Git/llvm-worktrees/main/lldb/test/API/driver/batch_mode/TestBatchMode.py", line 33, in test_batch_mode_no_commands_quits
self.assertEqual(proc.stdout, "")
AssertionError: 'The "bt" python commands have been instal[326 chars]p.\n' != ''
- The "bt" python commands have been installed and are ready for use.
- The "sd" python command has been installed and is ready for use.
- The "expr" python aliases have been installed and are ready for use.
- "malloc_info", "ptr_refs", "cstr_refs", "find_variable", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help.
```
I guess we could have a separate test for `--batch` with a test-local
`.lldibinit` that confirms we actually load the lldbinit before
quitting. Not sure how much value that would be. For now I just added
the `--no-lldbinit` to the test
|
|
Was failing on the Clang 17 green dragon matrix bot:
```
/Applications/Xcode_26.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.2.sdk/System/Library/Frameworks/vecLib.framework/Headers/Sparse/SolveImplementationTyped.h:678:9: error: use of undeclared identifier '__builtin_verbose_trap'
07:28:37 678 | __builtin_verbose_trap("unsupported", "LU factorization is not supported on this OS version");
07:28:37 | ^
07:28:37 /Applications/Xcode_26.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.2.sdk/System/Library/Frameworks/vecLib.framework/Headers/Sparse/SolveImplementationTyped.h:888:95: error: unrecognized platform name visionOS
07:28:37 888 | if(__builtin_available(macOS 15.5, macCatalyst 18.5, iOS 18.5, watchOS 11.5, tvOS 18.5, visionOS 2.5, *)) {
07:28:37 |
```
|
|
This PR updates type parsing in DIL to recognize user-defined types
(classes, namespaces, etc.), and allows this to be used in type casting.
|
|
Initial implementation of a [bytecode][1] synthetic provider. This is a follow up to
https://github.com/llvm/llvm-project/pull/114333 which implemented the bytecode
interpreter, support for summary formatters, and more.
rdar://169727764
[1]: https://lldb.llvm.org/resources/formatterbytecode.html
|
|
Reverts llvm/llvm-project#174348 due to reported failures on MacOS and
Arm 32-bit Linux.
|
|
Several languages support some sort of "breakpoint" function, which adds
ISA-specific instructions to generate an interrupt at runtime. However,
on some platforms, these instructions don't increment the program
counter. When LLDB sets these instructions it isn't a problem, as we
remove them before continuing, then re-add them after stepping over the
location. However, for breakpoint sequences that are part of the
inferior process, this doesn't happen - and so users might be left
unable to continue past the breakpoint without manually interfering with
the program counter.
This patch adds logic to LLDB to intercept SIGTRAPs, inspect the bytes
of the inferior at the program counter, and if the instruction looks
like a BRK or BKPT or similar, increment the pc by the size of the
instruction we found. This unifies platform behaviour (e.g. on x86_64,
LLDB debug sessions already look like this) and improves UX (in my
opinion, but I think it beats messing with stuff every break).
Some ISAs (like AArch64) require slightly different handling, as while
there are multiple possible instructions, we should be careful only to
find the ones likely to have been emitted by a compiler backend, and not
those inserted from (for example) the UB sanitizer, or any others.
There is an existing builtin-debugtrap test which was under the macos
folder before. I've now moved that to "functionalities", made it pure C
only, and updated it a little bit so that it works regardless of
platform.
What I've not done is change the existing code in debugserver which was
added by Jason Molenda about five years ago
(https://reviews.llvm.org/D91238, 92b036d). It might not be required any
more after this change. Reading the history there, it seems like it was
agreed that this behaviour (skipping over unknown bps) was the desired
end goal.
Fixes #56268
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
|
|
Fails on public green dragon arm64 bot with:
```
08:53:39 "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/./bin/dsymutil" -o "fat.out.dSYM" "fat.out"
08:53:39 warning: no debug symbols in executable (-arch x86_64)
08:53:39 warning: no debug symbols in executable (-arch x86_64h)
08:53:39 warning: no debug symbols in executable (-arch arm64)
08:53:39
08:53:39
08:53:39 runCmd: file -arch x86_64 /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lldb-test-build.noindex/macosx/posix_spawn/TestLaunchProcessPosixSpawn.test_apple_silicon/fat.out
08:53:39
08:53:39 warning: (x86_64) /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lldb-test-build.noindex/macosx/posix_spawn/TestLaunchProcessPosixSpawn.test_apple_silicon/fat.out empty dSYM file detected, dSYM was created with an executable with no debug info.
08:53:39 output: Current executable set to '/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lldb-test-build.noindex/macosx/posix_spawn/TestLaunchProcessPosixSpawn.test_apple_silicon/fat.out' (x86_64).
08:53:39
08:53:39
08:53:39 <bound method SBProcess.Kill of SBProcess: pid = 73406, state = exited, threads = 0, executable = fat.out>: success
08:53:39
08:53:39 FAIL: LLDB (/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang-arm64) :: test_apple_silicon (TestLaunchProcessPosixSpawn.TestLaunchProcessPosixSpawn)
08:53:39 runCmd: settings clear --all
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set symbols.enable-external-lookup false
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set target.inherit-tcc true
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set target.disable-aslr false
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set target.detach-on-error false
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set target.auto-apply-fixits false
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set plugin.process.gdb-remote.packet-timeout 60
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set symbols.clang-modules-cache-path "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-lldb/lldb-api"
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set use-color false
08:53:39
08:53:39 output:
08:53:39
08:53:39 runCmd: settings set show-statusline false
08:53:39
08:53:39 output:
08:53:39
08:53:39 UNSUPPORTED: LLDB (/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang-arm64) :: test_haswell (TestLaunchProcessPosixSpawn.TestLaunchProcessPosixSpawn) (Current CPU is not Haswell)
08:53:39 Restore dir to: /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/test
08:53:39 ======================================================================
08:53:39 FAIL: test_apple_silicon (TestLaunchProcessPosixSpawn.TestLaunchProcessPosixSpawn)
08:53:39 ----------------------------------------------------------------------
08:53:39 Traceback (most recent call last):
08:53:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 160, in wrapper
08:53:39 return func(*args, **kwargs)
08:53:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py", line 72, in test_apple_silicon
08:53:39 self.run_arch(exe, "x86_64")
08:53:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py", line 48, in run_arch
08:53:39 self.assertTrue(error.Success(), str(error))
08:53:39 AssertionError: False is not true : error: process exited with status -1 (lost connection)
08:53:39 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
08:53:39 ----------------------------------------------------------------------
08:53:39 Ran 2 tests in 5.686s
08:53:39
08:53:39 FAILED (failures=1, skipped=1)
```
|
|
Get the shared cache filepath and uuid that the inferior process is
using from debugserver, try to open that shared cache on the lldb host
mac and if the UUID matches, index all of the binaries in that shared
cache. When looking for binaries loaded in the process, get them from
the already-indexed shared cache.
Every time a binary is loaded, PlatformMacOSX may query the shared cache
filepath and uuid from the Process, and pass that to
HostInfo::GetSharedCacheImageInfo() if available (else fall back to the
old HostInfo::GetSharedCacheImageInfo method which only looks at lldb's
own shared cache), to get the file being requested.
ProcessGDBRemote caches the shared cache filepath and uuid from the
inferior, once it has a non-zero UUID. I added a lock for this ivar
specifically, so I don't have 20 threads all asking for the shared cache
information from debugserver and updating the cached answer. If we never
get back a non-zero UUID shared cache reply, we will re-query at every
library loaded notification. debugserver has been providing the shared
cache UUID since 2013, although I only added the shared cache filepath
field last November.
Note that a process will not report its shared cache filepath or uuid at
initial launch. As dyld gets a chance to execute a bit, it will start
returning binaries -- it will be available at the point when libraries
start loading. (it won't be available yet when the binary & dyld are the
only two binaries loaded in the process)
I tested this by disabling lldb's scan of its own shared cache
pre-execution -- only loading the system shared cache when the inferior
process reports that it is using that. I got 6-7 additional testsuite
failures running lldb like that, because no system binaries were loaded
before exeuction start, and the tests assumed they would be.
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
|
|
This reverts commit cc7292056683f592c33055bb6456d509201654ec.
This patch causes two tests to unexpectedly pass:
1. lldb-api.functionalities/tsan/cpp_global_location/TestTsanCPPGlobalLocation.py
2. lldb-api.functionalities/tsan/global_location/TestTsanGlobalLocation.py
Reverting to fix premerge. Not fixing forward so someone who is familiar
with LLDB can take a look and make sure those tests now should pass.
|
|
Previously the test was written in a way that may be flaky, fixed with
the following changes.
- The breakpoint are placed on functions and set during the
configuration stage of the protocol.
- Add the rpath to the test binary.
- Check we also hit the breakpoint we set directly using lldb.
|
|
Linux uses 0 for `RTLD_DEFAULT` opposite to macOS and BSD systems (they
use -2).
|
|
Fixes #179700
Simple fix, if we are in batch mode, don't go into an interactive
session after checking if there are commands to run.
Testing it is more tricky. I tried a shell test as I thought it would be
simplest. However to be able to FileCheck I had to pipe and the pipe
turns off the prompt because it's non-interactive. The prompt is the
thing that must not be printed.
So I've just spawned lldb as a subprocess. If it doesn't quit quickly
then something is wrong. The timeout is high not because it should
normally take that long, but because sometimes a process will get
stalled for a while and I don't want this to be flaky.
(though in theory it can get stalled for much longer than a minute)
If it does time out, the process will be cleaned up automatically. See
https://docs.python.org/3/library/subprocess.html#subprocess.run
> A timeout may be specified in seconds, it is internally
> passed on to Popen.communicate(). If the timeout expires,
> the child process will be killed and waited for.
|
|
Ran my python script from
https://github.com/llvm/llvm-project/pull/97043 over the repo again and
there were 2 duplicate test-cases that have been introduced since I last
did this.
Also one of the WASM classes had a duplicate method which I just
removed.
|
|
When I changed lldb so that the StopInfo's compute their own stop reason
data (before it was oddly done in SBThread::GetStopReasonData...) I
didn't notice that StopInfoMachException was relying on that routine's
default of returning the Value as the 0th exception data, and didn't
actually return its own data.
This fixes that, and makes us report the exception type, and the code
and subcode if the exception has them. I also added a test for this.
rdar://169755672
|
|
Fails on Windows with below error. Probably because we're not
constructing the AST from DWARF correctly for templates. Or perhaps
something to do with the DWARF index.
```
******************** TEST 'lldb-api :: lang/cpp/template-diagnostic-hint/TestTemplateDiagnosticHint.py' FAILED ********************
Script:
--
C:/Users/tcwg/scoop/apps/python/current/python.exe C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/llvm-project/lldb\test\API\dotest.py -u CXXFLAGS -u CFLAGS --env LLVM_LIBS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib --env LLVM_INCLUDE_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/include --env LLVM_TOOLS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin --arch aarch64 --build-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex --lldb-module-cache-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-lldb\lldb-api --clang-module-cache-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-api --executable C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/lldb.exe --compiler C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/clang.exe --dsymutil C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/dsymutil.exe --make C:/Users/tcwg/scoop/shims/make.exe --llvm-tools-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin --lldb-obj-root C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb --lldb-libs-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib --cmake-build-type Release --skip-category=watchpoint C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\template-diagnostic-hint -p TestTemplateDiagnosticHint.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 23.0.0git (https://github.com/llvm/llvm-project.git revision 4afce0cb3de8e9a849b5150471672f4bb6ee591b)
clang revision 4afce0cb3de8e9a849b5150471672f4bb6ee591b
llvm revision 4afce0cb3de8e9a849b5150471672f4bb6ee591b
Skipping the following test categories: watchpoint, libc++, libstdcxx, dwo, dsym, gmodules, debugserver, objc, fork, pexpect
--
Command Output (stderr):
--
UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_dsym (TestTemplateDiagnosticHint.TestCase.test_dsym) (test case does not fall in any category of interest for this run)
FAIL: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_dwarf (TestTemplateDiagnosticHint.TestCase.test_dwarf)
UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_dwo (TestTemplateDiagnosticHint.TestCase.test_dwo) (test case does not fall in any category of interest for this run)
======================================================================
FAIL: test_dwarf (TestTemplateDiagnosticHint.TestCase.test_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1844, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\template-diagnostic-hint\TestTemplateDiagnosticHint.py", line 14, in test
self.expect(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2569, in expect
self.fail(log_msg)
AssertionError: Ran command:
"expression some_template_func<int, long>(5)"
Got output:
note: Ran expression as 'C++14'.
error: <user expression 0>:1:1: use of undeclared identifier 'some_template_func'
1 | some_template_func<int, long>(5)
| ^~~~~~~~~~~~~~~~~~
Expecting sub string: "does not name a template but is followed by template arguments" (was not found)
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
Ran 3 tests in 0.601s
FAILED (failures=1, skipped=2)
```
|
|
Check if the client supports RunInTerminal before attempting to run in
the preferred terminal.
One less unknown reason for failed to launch
|
|
function templates (#179916)
Before:
```
(lldb) expression some_template_func<int, long>(5)
˄
╰─ error: 'some_template_func' does not name a template but is followed by template arguments
note: Ran expression as 'C++14'.
note: note: non-template declaration found by name lookup
```
After:
```
(lldb) expression some_template_func<int, long>(5)
˄
╰─ error: 'some_template_func' does not name a template but is followed by template arguments
note: Ran expression as 'C++14'.
note: note: non-template declaration found by name lookup
note: Naming template instantiation not yet supported. Template functions can be invoked via their mangled name. E.g., expression _Z3fooIiEvi(5)
```
There isn't a great way to get to the actual function being named (and
its mangled name) since we're just dealing with raw text. So I just
print an example mangled name.
This doesn't work for all template instantiations. E.g.,:
```
(lldb) p f.method<long>(10)
˄ ˄
│ ╰─ error: expected '(' for function-style cast or type construction
╰─ error: no member named 'method' in 'Foo<int>'
note: Ran expression as 'C++14'.
```
This is a consequence of how we construct the AST for template methods.
Once we fix that, this hint will get emitted there too.
Note this will also trigger in cases where no function is being called
(hence I used the defensive phrase "Template functions can be invoked").
rdar://135725807
|
|
This test was already disabled going from windows -> linux because it
was timing out there.
The PR: https://github.com/llvm/llvm-project/pull/179799 seems to have
exacerbated whatever this stall was, and now we're seeing it when
debugging from a linux host to a remote linux as well.
The native local host tests works correctly on all the bots that we
have, however. So I'm disabling the remote test till we can figure out
why this is problematic.
|
|
private state thread (#179799)
We have a problem when some code on the private state thread needs to
run an expression. The private state thread is the one that fetches
"raw" events from the Process Plugin and decides how to handle them. But
if the private state thread needs to fetch the processed events to drive
running an expression, it can't also be the thread processing the raw
events.
We solve this by swapping in a modal private state thread just to handle
the events from the expression evaluation. That worked until you could
cause the expression evaluation to happen from Python, because then it
wasn't just the fetching of events that matter, but also the state of
the process and the state of the runlocks. The modal private state
thread is really a modal version of the thread and its associated state.
This patch gathers all the relevant control parameters into a structure
which we can swap in and out when needed.
It also adds a test using the new "was_hit" breakpoint resolver
affordance, which, since it acts as an asynchronous breakpoint callback,
gets run on the private state thread, showing that with the change we
can call expressions in the `was_hit` callback without problems.
|
|
Tests in the same python file share the same build directory.
Although they are the same binary. The logs produced are different.
|
|
(#171482)
We want to reload the call stack whenever the frame providers are
updated. To do so, we now emit a `eBroadcastBitStackChanged` on all
threads whenever any changes to the frame providers take place.
I found this very useful while iterating on a frame provider in
lldb-dap. So far, the new frame provider only took effect after
continuing execution. Now the backtrace in VS-Code gets refreshed
immediately upon running `target frame-provider add`.
|
|
Improving stability of the TestDAP_launch_commands test.
When collecting output for verifying 'stopCommands' we were not waiting
for the output to finish, which could cause issues if the test is
running very fast.
|
|
EvaluateRequests handler now uses the target's context if no valid
frameId is provided, enabling evaluation of
global variables without requiring a valid stack frame.
In repl mode it now uses the last `successful` variable or command
expression, if the provided user's expression is empty.
Try to evaluate the expression if the evaluation context is `Unknown`
|
|
We are waiting for both stopped event at once.
We may not get both events within the (0.25 seconds) time interval to
fetch more events. Retry with the `DEFAULT TIMEOUT` if we got one of the
event.
Increase the `EVENT_QUIET_PERIOD`'s value for ASAN mode
Fixes #179648
|
|
Depends on:
* https://github.com/llvm/llvm-project/pull/177921
* https://github.com/llvm/llvm-project/pull/177926
(only last commit is relevant for this review)
This patch emits a workaround suggestion (in the form of a `note:`
diagnostic) when an expression fails due to trying to mutate state/call
functions with CV-qualifiers that are disallowed by C++ language rules
based on the context the expression is evaluated in. The note looks as
follows:
```
(lldb) expr next.method()
˄
╰─ error: 'this' argument to member function 'method' has type 'const Bar', but function is not marked const
note: Ran expression as 'C++14'.
note: note: 'method' declared here
note: Possibly trying to mutate object in a const context. Try running the expression with: expression --c++-ignore-context-qualifiers -- <your expression>
```
|
|
option (#177926)
Depends on:
* https://github.com/llvm/llvm-project/pull/177920
* https://github.com/llvm/llvm-project/pull/177922
* https://github.com/llvm/llvm-project/pull/179208
(only commit d8676d0ed9286777e1a1e9f625389540cc42c231 and later are
relevant for this review)
In https://github.com/llvm/llvm-project/pull/177922 we make expressions
run in C++ member functions honor the function qualifiers of the current
stop context. E.g., this means we can no longer run non-const member
functions when stopped in a const-member function.
To ensure users can still do this if they really need/want to, we
provide an option to not honor the qualifiers at all, leaving the
`__lldb_expr` minimally qualified, allowing it to call any
function/mutate any members.
|
|
(#177922)
We stopped marking `__lldb_expr` with the function qualifiers of the
method LLDB is stopped in ever since
`8bdcd522510f923185cdfaec66c4a78d0a0d38c0`. The assumption was that it
wasn't ever required for correctness (i.e., LLDB should just always
pretend it's in a mutable context). But since function qualifiers affect
overloading in C++, this assumption can lead to unexpected expression
evaluator behaviour. E.g., if a function is overloaded on qualifiers
(`const` vs. `non-const`), the expression evaluator would currently
always call the non-CV qualified overload.
This patch adds function qualifiers to `$__lldb_class::$__lldb_expr`
that resemble the qualifiers of the method that we're stopped in.
However, mutating variables or calling arbitrary member functions from
CV-qualified methods can be useful/is something users already may be
used to. To provide users with the ability to ignore the CV-qualifiers
of the current context, we will provide an expression evaluator flag
that switches this off in a follow-up patch.
|
|
(#179208)
The motivation here is that we don't want to pollute the SBAPI with
getters/setters for expression evaluation options that only apply to a
single language. The ultimate goal would be to have plugins register
additional options to the `expression` command when the plugin is
loaded. This patch only provides the minimal `SBExpressionOptions`
interface to set an option with an arbitrary name, which the language
plugin knows how to interpret. The underlying options dictionary is an
`StructuredData::Dictionary` so we can map strings to values of any
type. But the SBAPI just exposes setting a boolean value. Future
overloads of `SetLanguageOption` can provide setters for more types.
The boolean setter/getter will be used for the C++-specific option being
introduced in: https://github.com/llvm/llvm-project/pull/177926
|
|
Re-attemp landing of old commit:
https://github.com/llvm/llvm-project/commit/7fe3586cda5b683766ec6b6d5ca2d98c2baaf162
Co-authored-by: George Hu <georgehuyubo@gmail.com>
|
|
types (#179213)
This patch re-implements `TypeSystemClang::IsFloatingPointType` by
forwarding it to `clang::Type::isFloatingType`. The main difference is
that the latter returns false for float vector types. The motovation
here (apart from implementation simplicity) is that this is currently a
foot-gun because most callsites probably don't consider treating float
vector types. Callers should test for vectors explicitly using
`IsVectorType` (or use `GetTypeInfo`).
This patch makes all the callers of `IsFloatingPointType` now check
`GetTypeInfo() & eTypeIsFloat`. This is set for float vector types too,
so behaviour doesn't change.
To make sure we audit all the call-sites in `ValueObject.cpp`, I added a
helper `HasFloatRepresentation` (named after the
`clang::Type::hasFloatingRepresentation` API), which does the
`GetTypeInfo` check, and added a FIXME to it.
|
|
DAP_launch_io sends a continue request for a nonstopped process. Use
verify_process_exited instead.
|
|
Updates the 'stopped' event to use structure types.
Additionally, I adjusted the description to include the full
`GetStopDescription` that can have more details.
|
|
Added `ASanReport` for `ExceptionInfo` request.
|
|
(#178823)
When a user holds an SBFrame reference and then triggers an inferior
function
call (via expression evaluation or GetExtendedBacktraceThread),
variables in
that frame become inaccessible with "register fp is not available"
errors.
This happens because inferior function calls execute through
ThreadPlanCallFunction, which calls ClearStackFrames() during cleanup to
invalidate the unwinder state. ExecutionContextRef objects in the old
SBFrames
were tracking StackFrameLists via weak_ptr, which became stale when
ClearStackFrames() created new instances.
The fix uses stable StackFrameList identifiers that persist across
ClearStackFrames():
- ID = 0: Normal unwinder frames (constant across all instances)
- ID = sequential counter: Scripted frame provider instances
ExecutionContextRef now stores the frame list ID instead of a weak_ptr,
allowing
it to resolve to the current StackFrameList with fresh unwinder state
after an
inferior function call completes.
The Thread object preserves the provider chain configuration
(m_provider_chain_ids and m_next_provider_id) across ClearStackFrames()
so
that recreated StackFrameLists get the same IDs. When providers need to
be
recreated, GetStackFrameList() rebuilds them from the persisted
configuration.
This commit also fixes a deadlock when Python scripted frame providers
call
back into LLDB during frame fetching. The m_list_mutex is now released
before
calling GetFrameAtIndex() on the Python scripted frame provider to
prevent
same-thread deadlock. A dedicated m_unwinder_frames_sp member ensures
GetFrameListByIdentifier(0) always returns the current unwinder frames,
and
proper cleanup in DestroyThread() and ClearStackFrames() to prevent
modules
from lingering after a Thread (and its StackFrameLists) gets destroyed.
Added test validates that variables remain accessible after
GetExtendedBacktraceThread triggers an inferior function call to fetch
libdispatch Queue Info.
rdar://167027676
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This reapplies #175292 with the fixed test. The original test used
integer types with different bit widths on different platforms.
----- Original message:
This allows expressions that use these conversions to be executed when
JIT is not available.
|
|
This restores files that were unintentionally added to commit
21a74f527839b5b8dd882e62a25093d980c79078, 'Revert "[lldb] Add FP
conversion instructions to IR interpreter (#175292)"'
|
|
Closes #119784
Probably closes #147105 as well, but I couldn't test due to #156473:
This PR fixes two bugs:
1. It generates unique variable reference IDs per suspended debuggee
state.
2. It stores all created variables in a stopped state instead of
dropping variables in unselected scopes. So it can properly handle all
scope/variable requests
It does this by storing all variables in their respective scopes and
using that mapping in request handlers that relied on the old mapping.
It dynamically creates new variable/scope IDs instead of resetting IDs
whenever a new scope is created.
I also removed some unused code as well.
---------
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
|
|
This reverts commit c2082a65b7fc8e7587ed07170e250820d6bbda1d.
|
|
This allows expressions that use these conversions to be executed when
JIT is not available.
|
|
(#178734)
When setting the enabled state of a breakpoint name via the API, the
change was not being propagated to breakpoints using that name.
This was inconsistent with the CLI behaviour where `breakpoint name
configure --enable/--disable` correctly updates all associated
breakpoints.
|
|
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
Related radar: rdar://165708771
|
|
(#177676)
## Description
Contribution to this topic [Rich Disassembler for
LLDB](https://discourse.llvm.org/t/rich-disassembler-for-lldb/76952),
this part.
```
The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this
```
----
This pr replaces #174847
As was suggested in [this
comment](https://github.com/llvm/llvm-project/pull/174847#issuecomment-3757015552),
implement access to variable annotations from `SBInstruction` class
itself.
Notes:
- :white_check_mark: did run black formatter on the python file;
## Testing
Run test with
```sh
./build/bin/lldb-dotest -v -p TestVariableAnnotationsDisassembler.py lldb/test/API/functionalities/disassembler-variables
```
all tests (9 existing + 1 newly added) are passing
<details>
<summary>screenshot 2026-01-23</summary>
build from the latest commit 08f00730b5768a8e3f7039d810084fabaaa24470
<img width="1506" height="562" alt="image"
src="https://github.com/user-attachments/assets/69516353-3432-47df-ae45-c40b51ec14c4"
/>
</details>
<details>
<summary>screenshot 2026-01-29</summary>
build from the latest commit f48a1a2c10f96a457ca6844be2ccc9406d3d57a0
<img width="1232" height="740" alt="image"
src="https://github.com/user-attachments/assets/9d104ce6-36c3-430b-98fe-f028f83a6b6d"
/>
</details>
---------
Signed-off-by: Nikita B <n2h9z4@gmail.com>
|
|
This patch adds the coreFilePath, if applicable, to the target
statistics for LLDB. My primary motivation here is sanity check user
reports when they say I had an issue with a specific corefile and then
validating it was in fact that specifies corefile, as right now there is
no guaruntee the filename and the process/target name will be the same.
|
|
non-darwin platforms may have incorrect stop information location
heuristics. Enable assertion once UBSan stopInfo heuristic is updated.
I hit this locally, I don't see it hitting any CI bot but should, Mostly
likely the CI linux bots may not have `compiler_rt` run time enabled.
see
https://github.com/llvm/llvm-project/pull/177964#discussion_r2732271531
|
|
the ubsan decorator previously assumes the platform is macOS.
macOS has an extra underscore in symbols names match two or more.
uses the llvm-nm that is built instead of the system's nm.
|
|
These test the existing behaviour before I work on #177570.
I chose "breakpoint set" because it has options with ANSI underlines
in the description.
The tests cover no ANSI (use-colour off) and with ANSI (use-color on).
The latter is where we have problems right now.
|
|
libraries from memory (#177289)
This patch enables ELF core files to be loaded and still show
executables and shared libraries. Functionality includes:
- Load executable and shared libraries from memory if ELF headers are
available
- Create placeholder for missing shared libraries and executable.
Previously you just wouldn't get anything in the "image list" if no
executable was provided.
|
|
In the exceptionInfo request I've added additional information for crash
data, instrumentation data and more detailed exception data.
For example, when UBSan is enabled, you now see additional information
in the exception stack trace about the detected issue:
<img width="1728" height="538" alt="Screenshot 2026-01-15 at 3 05 08 PM"
src="https://github.com/user-attachments/assets/b761af2c-90ac-4eb7-9926-3ab133f1b753"
/>
I included a new test for stopping at `lldb::eStopReasonInstrumentation`
and ensuring we have additional information reported.
---------
Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
|
