LLDB breakpoint conditions take an expression that's evaluated using the
language of the code where the breakpoint is located. Users have asked
to have an option to tell it to evaluate the expression in a specific
language.
This is feature is especially helpful for Swift, for example for a
condition based on the value in memory at an offset from a register.
Such a condition is pretty difficult to write in Swift, but easy in C.
This PR adds a new argument (-Y) to specify the language of the
condition expression. We can't reuse the current -L option, since you
might want to break on only Swift symbols, but run a C expression there
as per the example above.
rdar://146119507
Fixes [#68035](https://github.com/llvm/llvm-project/issues/68035), where
an inconsistency in the order of "Process launched" and "Process
stopped" messages occurs during `process launch`.
The fix involves adjusting the message output sequence in
`CommandObjectProcessLaunch::DoExecute` within
`source/Commands/CommandObjectProcess.cpp`. This ensures "Process
launched" consistently precedes "Process stopped" when executing
commands with the '-o' flag, i.e., non-interactive mode.
Upon implementing this change, two tests failed:
`lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test` and
`lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test`. These failures
were expected as they relied on the previous, now-corrected message
order. Updating these tests to align with the new message sequence is
part of this PR's scope.
lldb/test/Shell/Breakpoint/breakpoint-command.test adds a python
command, to be executed when a breakpoint hits, that writes out a
number. It then runs, hits the breakpoint and checks that the number is
present exactly once.
The problem is that on some systems the test can be run in a filepath
that happens to contain the number (e.g. auto-generated directory
names). The number is then detected multiple times and the test fails.
This patch fixes the issue by using a string instead, particularly a
string with spaces, which is very unlikely to be auto-generated by any
system.
My local build is with -DLLVM_ENABLE_PROJECTS=lldb, but I don't compile
with -DLLDB_ENABLE_PYTHON=True or -DLLDB_ENABLE_LUA=True. This results
in there being no script interpreter.
The test lldb/test/Shell/Breakpoint/breakpoint-command.test has an
implicit dependency on a script interpreter being available.
This patch makes that dependency clear. If you have a script
interpreter, the test gets run, otherwise it gets skipped. This means
that folks (like me) who naively use -DLLVM_ENABLE_PROJECTS=lldb can
continue to run check-all without breakages.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D139463
The functionality is fine (we don't run the breakpoint command twice), but this test forgot to call `FileCheck` and isn't checking the same value isn't there twice..
Currently, ppc64le and ppc64 (defaulting to big endian) have the same
descriptor, thus the linear scan always return ppc64le. Handle that through
subtype.
This is a recommit of f114f009486816ed4b3bf984f0fbbb8fc80914f6 with a new test
setup that doesn't involves (unsupported) corefiles.
Differential Revision: https://reviews.llvm.org/D124760
Migrate to using ReportError to report a failure to evaluate a
watchpoint condition. I had already done so for the parallel code for
breakpoints.
In the process, I noticed that I accidentally regressed the error
reporting for breakpoint conditions by dropping the call to
GetDescription. This patch rectifies that and adds a test.
Because the call to GetDescription expects a Stream*, I also switches
from using a raw_string_ostream to a StreamString for both breakpoints
and watchpoints.
At first, lli only supported lazy mode for ORC. Greedy mode was added with e1579894d205 and is the default settings now. JITLoaderGDB tests don't rely on laziness, so we can switch them to greedy and remove some complexity.
When executing a script command in HandleCommand(s) we currently print
its output twice
You can see this issue in action when adding a breakpoint command:
(lldb) b main
Breakpoint 1: where = main.out`main + 13 at main.cpp:2:3, address = 0x0000000100003fad
(lldb) break command add 1 -o "script print(\"Hey!\")"
(lldb) r
Process 76041 launched: '/tmp/main.out' (x86_64)
Hey!
(lldb) script print("Hey!")
Hey!
Process 76041 stopped
The issue is caused by HandleCommands using a temporary
CommandReturnObject and one of the commands (`script` in this case)
setting an immediate output stream. This causes the result to be printed
twice: once directly to the immediate output stream and once when
printing the result of HandleCommands.
This patch fixes the issue by introducing a new option to suppress
immediate output for temporary CommandReturnObjects.
Differential revision: https://reviews.llvm.org/D103349
LLVM OrcJIT is shifting from RuntimeDyld to JITLink. Starting with D96627 I am planning to add debug support. It would be great to have test coverage for it in LLDB early on.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D96634
Part 2 of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 Part 1 was D61611 a while ago.
The in-memory object files we obtain from JITLoaderGDB are not yet relocated. It looks like this used to happen on the LLDB side and my guess is that it broke with D38142. (However, it's hard to tell because the whole thing was broken already due to the bug in part 1.) The patch moved relocation resolution to a later point in time and didn't apply it to in-memory objects. I am not aware of any reason why we wouldn't resolve relocations per-se, so I made it unconditional here. On Debian, it fixes the bug for me and all tests in `check-lldb` are still fine.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90769
causing the -D option for breakpoint set command to be incorrectly parsed.
Patch by Martin Svensson.
Differential Revision: https://reviews.llvm.org/D69425
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
