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.
This patch adds cross platform (Darwin, Linux, Windows) commands in
`Makefile.rules` which is used to build lldb test targets.
This maps POSIX commands like `mkdir -p` to their Windows equivalent,
which allows to create cross platform `Makefile` for lldb's test
targets. This is currently not needed by any test but might become
useful later as we are working on enabling more lldb Windows tests.
This was originally done in the `swiftlang/llvm-project` fork
(https://github.com/swiftlang/llvm-project/pull/12127)
VS Code and node versions should be synchronized. We use node >= 18.19,
so expected VS Code version is 1.90.0. I checked it using this
[info](https://github.com/ewanharris/vscode-versions).
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.
Add handling for `STT_TLS` (thread-local storage) symbols in the ELF
symbol parsing code. Previously, TLS symbols like `errno` from glibc
were not recognized because `STT_TLS` was not handled in the symbol type
switch statement.
This treats TLS symbols as data symbols (`eSymbolTypeData`), similar to
`STT_OBJECT`. The actual TLS address resolution is already implemented
in `DynamicLoaderPOSIXDYLD::GetThreadLocalData()` which uses the DWARF
`DW_OP_form_tls_address` opcode to calculate thread-local addresses.
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
This ivar was passed to the thread function for the private state thread
- mostly because the equivalent variable was passed in in the original
version of the code. But it was never used, so I didn't notice that the
ivar equivalent wasn't being initialized. I'm going to keep the ivar
because it will be useful when debugging to easily see whether you are
on the main or secondary private state thread.
So in this change, I set m_is_secondary_thread properly in the
constructor, but remove passing it to the thread function since it
wasn't needed there.
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)
```
When working with a MainLoop, if the file reaches the EOF it will
immediately fire the read handle callback. We cannot readily determine
if the file is at EOF or if the file is pointing to a socket/pipe that
has consumed all the current data in the buffer but the remote end has
not yet hung up. This is causing JSONTransport to continuously fire the
OnRead callback trigging repeated calls to the
`MessageHandler::OnClose`.
Since MainLoop does not perform the actual read, we need to adjust the
behavior of JSONTransport to fully own the read handle.
This change moves the ownership of the `MainLoop::ReadHandleUP` and
additionally own a reference to the `MainLoop` itself to ensure the loop
outlives the JSONTransport object.
This allows us to remove the handle immediately when we detect an EOF /
hang up has occurred.
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
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>
Since ce03a862372a6f36d2fcf80dc80052aa155fcae8 and
427bb1cc1b09ea68b8a13a667810681ba4074f6b, mips64 support for POSIX is
orphaned. Remove any POSIX_mips64 code and other code we missed in those
commits.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
The end line entry calculated from the instruction's end address is
unreliable and could produce incorrect source ranges. especially if the
instruction spans multiple lines.
We can end in situations where the current end line is the next start
line and the source line is show to the client twice. confusing users
what maps to what.
| With EndLine |
| :------------: |
| <img width="892" height="486" alt="Screenshot 2026-02-05 at 21 37 08"
src="https://github.com/user-attachments/assets/f2fef592-5754-4168-bf93-2baba4742c5d"
/> |
| Without Endline |
| :---------------: |
| <img width="892" height="486" alt="Screenshot 2026-02-05 at 21 59 29"
src="https://github.com/user-attachments/assets/538dd462-9c7f-4483-804c-65fd83b5f2f2"
/>|
Or the endline is smaller than the startline.
```json
{
"address": "0x5555555557B4",
"column": 3,
"endLine": 2,
"instruction": "add rsp, 0x20 ",
"instructionBytes": "48 83 c4 20",
"line": 17,
"location": {
"name": "test.cpp",
"path": "/buildbot/test_process/test.cpp"
}
},
```
The functionality was removed in
d3173f4ab61c17337908eb7df3f1c515ddcd428c after being broken for a long
time.
There's a small risk someone is still passing the option, but I think
it's time to remove it and they can fix their scripts.
Taking advantage of a few new SPI in macOS 26.4 libdyld, it is possible
for lldb to load binaries out of a shared cache binary blob, instead of
needing discrete files on disk. lldb has had one special case where it
has done this for years -- if the debugee process and lldb itself are
using the same shared cache, it could create ObjectFiles based on its
own memory contents. This new method requires only the shared cache on
disk, not depending on it being mapped into lldb's address space
already.
In HostInfoMacOSX.mm, we create an array of binaries in lldb's shared
cache, by one of two methods depending on the availability of SPI/SDKs.
This PR adds a new third method for loading lldb's shared cache off disk
as a proof of concept. It will prefer this new method when the needed
SPI are available at runtime. There is also a user setting to disable
this new method in case we uncover a problem as it is deployed.
I did change the internal store of the shared cache files from a single
array, to being organized by shared cache UUIDs, so we can have multiple
shared caches indexed in the future.
In HostInfoBase.h's SharedCacheImageInfo class, you can now create an
ImageInfo with a DataExtractorSP or a void* baton. I added GetUUID and
GetExtractor methods, and the latter will use the libdyld SPI to map the
segments for a specific binary into lldb's memory and return a
DataExtractorSP.
The setting is currently called symbols.shared-cache-binary-loading.
In DynamicLoaderDarwin::FindTargetModuleForImageInfo there was an
ordering mistake where we would always consult the HostInfoMacOSX.mm
shared cache provider, instead of checking lldb's own global module
cache first when looking for a binary, resulting in creating a new
Module repeatedly for shared cache binaries with the new method, parsing
the symbol table repeatedly. I fixed the ordering so we look at existing
Modules before we check the shared cache for one.
In ObjectFileMachOTest, it tests a TEXT and a DATA symbol, checking that
the contents of the function/data object match the bytes we got from the
shared cache. The test was using a DATA_DIRTY symbol, which was fine
when using lldb's own shared cache memory, but when we worked on the
shared cache binary on-disk directly, we were seeing different values
for the bytes because of relocations in there. I changed this to a
constant DATA symbol.
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Alex Langford <nirvashtzero@gmail.com>
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.
This changes VirtualDataExtractor's GetByteSize to return the virtual
byte size of the buffer (external users only understand the data
contents in terms of the virtual sizes & offsets). There are check
methods in DataExtractor that check they are not going off the end of a
buffer, they usually use the BytesLeft() method. There are a couple of
callers of BytesLeft() externally, but it is predominantly an internal
use API. I have BytesLeft() use the physical size of the buffer, not the
virtual size, for the benefit of the DataExtractor methods. (and to
avoid duplicating all of them down in VirtualDataExtractor)
Another problem is the we call SetData on DataExtractorSP's (e.g. see
the ObjectFile ctor) with the DataBuffer it already has, an offset of 0,
and the GetByteSize. A no-op for a DataExtractor that is already using
that DataBuffer. But SetData would try to use that length as a physical
size, and truncate the buffer that the DataExtractor would accept.
I added VirtualDataExtractor subclass methods for the SetData's, detect
(1) data being added to an uninitialized DataExtractor, (2) the same
data / offset / length as currently being used is added to the
DataExtractor (a no-op), or (3) we're genuinely changing the data source
or setting an offset / length that is different. This final case we're
not ready to handle today, I added asserts for them so we can catch it
in debug builds, and then I clear the LookupTable and add a no-op entry
so this extractor will behave like a plain DataExtractor -- because I
don't know better to do. If we genuinely need to handle this case, and
I'm pretty sure we don't need to, I'd have to assume that we're taking a
subset of the original data source (an offset & length), so we'd need to
update all of the LookupTable entries to reflect the new offsets, and
remove entries that are no longer referring to the subsetted range. I'll
leave that until there's any evidence it's actually needed.
rdar://148939795
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.
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`.
I noticed that Module::GetMemoryObjectFile populates a Status object
upon error but it's effectively dropped on the floor. Instead, the
clients can report the error as desired.
At the moment, all clients are either (1) consuming the error because
it's only trying to find a module, or (2) log the error and bail out
early. I tried to preserve existing behavior as faithfully as possible.
We have gotten reports of an occasional deadlock on shutdown. The
Driver::MainLoop thread is shutting down, and gets stuck here:
Thread 0x3c017c
start
main
Driver::MainLoop()
lldb::SBDebugger::RunCommandInterpreter(bool, bool)
lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&)
lldb_private::Debugger::RunIOHandlers()
lldb_private::Debugger::PopIOHandler(std::__1::shared_ptr<lldb_private::IOHandler>
const&)
lldb_private::Editline::Cancel()
lldb_private::LockableStreamFile::Lock()
std::__1::recursive_mutex::lock()
It has acquired the IO Handler list lock (in PopIOHandler) and is stuck
trying to get the debugger output stream lock.
Meanwhile, the event-handler thread is doing:
Thread 0x3c01d3
thread_start
_pthread_start
lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(void*)
lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*)
std::__1::__function::__func<lldb_private::Debugger::StartEventHandlerThread()::$_0,
void* ()>::operator()()
lldb_private::Debugger::DefaultEventHandler()
lldb_private::Statusline::~Statusline()
lldb_private::Statusline::UpdateScrollWindow(lldb_private::Statusline::ScrollWindowMode)
lldb_private::Debugger::RefreshIOHandler()
std::__1::recursive_mutex::lock()
UpdateScrollWindow gets the debugger output stream lock, and sends some
data to the output, then it calls RefreshIOHandler while still holding
the Debugger output stream lock. That's the problem, since if it gets
that lock before Editline::Cancel() completes, we'll get this deadlock.
The solution is simple, there's no reason why UpdateScrollWindow should
hold the debugger output lock when it calls RefreshIOHandler. If that
refresh ends up needing to write to the debugger output, it can take the
lock more narrowly at that point. This fixed the deadlock because after
yielding the output lock, the second thread waits on the first to get
the IO Handler lock. Meanwhile the first thread can now acquire the
debugger output lock and finish the Cancel, and exit PopIOHandler which
will allow the second thread to make progress in turn.
I couldn't figure out any way to test this...
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.
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>
FreeBSD has moved from svn to git. Use https://cgit.freebsd.org/src
instead as it is the source of truth. i386 and mips64 were no longer
supported as of FreeBSD 15 and 14, respectively, so link stable branch
instead of main branch. See [FreeBSD platforms
page](https://www.freebsd.org/platforms/).
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
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
In FreeBSD, allproc is a prepend list and new processes are appended at
head. This results in reverse pid order, so we first need to order pid
incrementally then print threads according to the correct order.
Before:
```
Process 0 stopped
* thread #1: tid = 101866, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015882f780, flags=259) at sched_ule.c:2448:26, name = '(pid 12991) dtrace'
thread #2: tid = 101915, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80158825780, flags=259) at sched_ule.c:2448:26, name = '(pid 11509) zsh'
thread #3: tid = 101942, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80142599000, flags=259) at sched_ule.c:2448:26, name = '(pid 11504) ftcleanup'
thread #4: tid = 101545, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80131898000, flags=259) at sched_ule.c:2448:26, name = '(pid 5599) zsh'
thread #5: tid = 100905, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80131899000, flags=259) at sched_ule.c:2448:26, name = '(pid 5598) sshd-session'
thread #6: tid = 101693, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015886e780, flags=259) at sched_ule.c:2448:26, name = '(pid 5595) sshd-session'
thread #7: tid = 101626, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801588be000, flags=259) at sched_ule.c:2448:26, name = '(pid 5592) sh'
...
```
After:
```
(lldb) thread list
Process 0 stopped
* thread #1: tid = 100000, 0xffffffff80bf9322 kernel`sched_switch(td=0xffffffff81abe840, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel'
thread #2: tid = 100035, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d9780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_0'
thread #3: tid = 100036, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d9000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_1'
thread #4: tid = 100037, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d8780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_2'
thread #5: tid = 100038, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d8000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_3'
thread #6: tid = 100039, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d7780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_4'
thread #7: tid = 100040, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d7000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_5'
...
```
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
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>
```
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.
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
Allows API tests to pass `SBExpressionOptions` when testing a successful
expression evaluation with `expect_expr`. Currently one would have to
use `SBFrame::EvaluateExpression` or pass the option as an argument to
the raw command (via `expect()` or `HandleCommand()`).
Chose not to do the `SetIgnoreBreakpoints`/`SetAutoApplyFixIts` with the
assumption that most expression evaluation tests don't actually need to
care about these. If the options are passed explicitly, lets use them
as-is. Otherwise default to the old options.
First usage of this new parameter would be in
https://github.com/llvm/llvm-project/pull/177926
