We got a bug report that this message is confusing. In this particular
case, the line zero was due to compiler tail merging (in optimized
code). The main issue was the "no source code" part: in this case it's
kind of incorrect because -- even though we can't really know that --
the address is arguably associated with *multiple* lines of source code.
I've tried to make the new wording more neutral, and added a wink
towards compiler optimizations. I left out the "compiler generated" part
of the message because I couldn't find a way to squeeze that in nicely.
I'm also not entirely sure what it was referring to -- if this was
(just) function prologue/epilogue, then maybe leaving it out is fine, as
we're not likely to stop there anyway (?)
I also left out the function name, because:
- for template functions it gets rather long
- it's already present in the message, potentially twice (once in the
"frame summary" line and once in the snippet of code we show for the
function declaration)
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This patch improves the formatting of editline completions. The current
implementation is naive and doesn't account for the terminal width.
Concretely, the old implementation suffered from the following issues:
- We would unconditionally pad to the longest completion. If that
completion exceeds the width of the terminal, that would result in a lot
of superfluous white space and line wrapping.
- When printing the description, we wouldn't account for the presence of
newlines, and they would continue without leading padding.
The new code accounts for both. If the completion exceeds the available
terminal width, we show what fits on the current lined followed by
ellipsis. We also no longer pad beyond the length of the current line.
Finally, we print the description line by line, with the proper leading
padding. If a line of the description exceeds the available terminal
width, we print ellipsis and won't print the next line.
Before:
```
Available completions:
_regexp-attach -- Attach to process by ID or name.
_regexp-break -- Set a breakpoint using one of several shorthand
formats.
_regexp-bt -- Show backtrace of the current thread's call sta
ck. Any numeric argument displays at most that many frames. The argument 'al
l' displays all threads. Use 'settings set frame-format' to customize the pr
inting of individual frames and 'settings set thread-format' to customize th
e thread header. Frame recognizers may filter thelist. Use 'thread backtrace
-u (--unfiltered)' to see them all.
_regexp-display -- Evaluate an expression at every stop (see 'help
target stop-hook'.)
```
After:
```
Available completions:
_regexp-attach -- Attach to process by ID or name.
_regexp-break -- Set a breakpoint using one of several shorth...
_regexp-bt -- Show backtrace of the current thread's call ...
_regexp-display -- Evaluate an expression at every stop (see 'h...
```
rdar://135818198
First, `SRE_Pattern` does not exist on newer Python's, use
`type(re.compile(''))` like other Python extensions do. The dynamic type
is because some earlier versions of Python 3 do not have `re.Pattern`.
Second, `SBModule` has a `file` property, not a `path` property.
"statistics dump" currently report the statistics of all targets in
debugger instead of current target. This is wrong because there is a
"statistics dump --all-targets" option that supposed to include
everything.
This PR fixes the issue by only report statistics for current target
instead of all. It also includes the change to reset statistics debug
info/symbol table parsing/indexing time during debugger destroy. This is
required so that we report current statistics if we plan to reuse
lldb/lldb-dap across debug sessions
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
This commit adds support for column breakpoints to lldb-dap.
To do so, support for the `breakpointLocations` request was
added. To find all available breakpoint positions, we iterate over
the line table.
The `setBreakpoints` request already forwarded the column correctly to
`SBTarget::BreakpointCreateByLocation`. However, `SourceBreakpointMap`
did not keep track of multiple breakpoints in the same line. To do so,
the `SourceBreakpointMap` is now indexed by line+column instead of by
line only.
See http://jonasdevlieghere.com/post/lldb-column-breakpoints/ for a
high-level introduction to column breakpoints.
I ran into this while look at a different bug (patch coming soon). This
function has only two callers. The first is SBTypeStaticField::GetName
(which doesn't care about templates), and the other is
CompilerDecl::GetCompilerContext (in the TypeQuery constructor), which
does want template arguments.
This function was (normally) returning the name without template args.
Since this code is only used when looking up a type in another shared
library, the odds of running into this bug are relatively low, but I add
a test to demonstrate the scenario and the fix for it nonetheless.
Amazingly (and scarily), this test actually passes without this change
in the default configuration -- and only fails with
-gsimple-template-names. The reason for that is that in the
non-simplified case we create a regular CXXRecordDecl whose name is
"bar<int>" (instead of a template record "foo" with an argument of
"int"). When evaluating the expression, we are somehow able to replace
this with a proper template specialization decl.
The newly added
test/API/functionalities/scripted_process_empty_memory_region/dummy_scripted_process.py
imports
examples/python/templates/scripted_process.py
which only has register definitions for x86_64 and arm64.
Only run this test on those two architectures for now.
A scripted process implementation might return an SBMemoryRegionInfo
object in its implementation of `get_memory_region_containing_address`
which will have an address 0 and size 0, without realizing the problems
this can cause. Several algorithms in lldb will try to iterate over the
MemoryRegions of the process, starting at address 0 and expecting to
iterate up to the highest vm address, stepping by the size of each
region, so a 0-length region will result in an infinite loop. Add a
check to Process::GetMemoryRegionInfo that rejects a MemoryRegion which
does not contain the requested address; a 0-length memory region will
therefor always be rejected.
rdar://139678032
In particular, this allows `bt -u`.
Note that this passthrough behavior has precedent in `_regexp-break`,
where `b (-.*)` is expanded to `breakpoint set %1`.
Previously this used `var` as both an lldb command and variable in the
source to validate the behavior of the 'auto' repl mode. However, `var`
seems to occasionally fail in the CI test when attempting to print some
c++ types. Instead switch the command and variable name to `list` which
should not run the dynamic variable formatting code for c++ objects.
This should fix#116041.
When retrieving the location of the function declaration, we were
dropping the file component on the floor, which resulted in an amusingly
confusing situation were we displayed the file containing the
implementation of the function, but used the line number of the
declaration. This patch fixes that.
It required a small refactor Function::GetStartLineSourceLineInfo to
return a SupportFile (instead of just the file spec), which in turn
necessitated changes in a couple of other places as well.
Lua 5.3 and Lua 5.4 are similar enough that we can easily support both
in LLDB. This patch adds support for building LLDB with both and updates
the documentation accordingly.
Some API tests (compiler calls) create a lot of garbage and cause
unexpected behavior in case of Windows host and Linux target, e.g.
```
lldb/test/API/commands/process/attach/%SystemDrive%/
lldb/test/API/functionalities/deleted-executable/%SystemDrive%/
lldb/test/API/functionalities/exec/%SystemDrive%/
lldb/test/API/functionalities/load_unload/%SystemDrive%/
lldb/test/API/functionalities/target-new-solib-notifications/%SystemDrive%/
lldb/test/API/functionalities/thread/create_after_attach/%SystemDrive%/
```
It can be fixed by transfer some standard Windows environment variables
into API tests.
The existing XFAIL was being ignored because of the `expectedFailureDarwin`
causing failures on the matrix macOS bot:
```
======================================================================
FAIL: test_inline_static_members_dwarf5_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 151, in test_inline_static_members_dwarf5
self.check_inline_static_members("-gdwarf-5")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 129, in check_inline_static_members
self.check_global_var("A::int_val", "const int", "1")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang
======================================================================
FAIL: test_shadowed_static_inline_members_dwarf5_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 205, in test_shadowed_static_inline_members_dwarf5
self.check_shadowed_static_inline_members("-gdwarf-5")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 192, in check_shadowed_static_inline_members
self.check_global_var("ns::Foo::mem", "const int", "10")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang
----------------------------------------------------------------------
```
The `compiler` parameter is not supported in the `expectedFailureDarwin`
decorator.
Change the decorator to `expectedFailureAll`, which is fine because
this only affects the `dsym` variant (which is only a macOS variant).
Follow-up to https://github.com/llvm/llvm-project/pull/111859. Prior
to this PR we would never run these tests with DWARFv5 on older Clang
versions (since default wasn't DWARFv5 on macOS until recently). The
patch explicitly started running some of these tests with DWARFv5.
These were failing on the macOS matrix bot (with Clang-15/Clang-17).
```
======================================================================
FAIL: test_inline_static_members_dwarf5_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 150, in test_inline_static_members_dwarf5
self.check_inline_static_members("-gdwarf-5")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 129, in check_inline_static_members
self.check_global_var("A::int_val", "const int", "1")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
```
https://github.com/llvm/llvm-project/pull/111859 fixed these tests for
DWARFv4 on Linux by adjusting the manual index. As part of the change we
unXFAILed these tests for DWARFv4 on all platforms. However, the manual
index isn't used on macOS so they're still broken. This patch reverts
the XFAIL on Darwin for DWARFv4.
Example CI failure:
```
FAIL: test_inline_static_members_dwarf4_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 153, in test_inline_static_members_dwarf4
self.check_inline_static_members("-gdwarf-4")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 129, in check_inline_static_members
self.check_global_var("A::int_val", "const int", "1")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
```
The changes in 461f859a72 (llvm/llvm-project#65974) resulted in a change
in behavior not just for completion, but also for selection of inexect
commands.
Since many use `e` to mean `expression`, this change adds an alias for
`e`. Note that the referenced change similarly aliases `h` to `help`.
In DWARF 4 and earlier `static const` members of structs, classes and
unions have an entry tag `DW_TAG_member`, and are also tagged as
`DW_AT_declaration`, but otherwise follow the same rules as
`DW_TAG_variable`.
clang when given -g on Windows produces a PDB file. For whatever reason,
the test doesn't work with that.
-gdwarf produces DWARF regardless of platform.
Fixes 803f957e87.
I have to check for the sc list size being changed by the call-site
search, not just that it had more than one element.
Added a test for multiple CU's with the same name in a given module,
which would have caught this mistake.
We were also doing all the work to find call sites when the found decl
and specified decl's only difference was a column, but the incoming
specification hadn't specified a column (column number == 0).
When you set a "next branch breakpoint" and run to it while stepping,
you have to claim the stop at that breakpoint to be the top of the
inlined call stack, or you will seem to "step in" and then plans might
try to step back out again.
This records the PrefferedLineEntry for next branch breakpoints and adds
a test to make sure this works.
This reverts commit 25909b811a due to
unresolved questions about the behavior of "frame var" and ValueObject
in the presence of references (see the original patch for discussion).
Internally we use bazel in a way in which it can drop you in a LLDB
session with the target launched in a particular cwd, which is needed
for things to work. We've been making this automation work via `process
launch -w`. However, if later the user wants to restart the process with
`r`, then they end up using a different cwd for relaunching the process.
As a way to fix this, I'm adding a target-level setting that allows
configuring a default cwd used for launching the process without needing
the user to specify it manually.
A Clang change introduced in this version breaks this test. Said
change was reverted in `52a9ba7ca4fb9427706c28bb3ca15f7a56eecf3f`
in newer versions of Clang.
Remove lldb-repro which was used to run the test suite against a
reproducer. The corresponding functionality has been removed from LLDB
so there's no need for the tool anymore.
We had to disable the tests for libc++ <= 15 because the `std::ranges`
functions were not available, yet.
Also, on libc++17 there was still an additional `__fn` struct withing
`ranges::__sort`. The test expectation was updated to use a regular
expression, so we can match both the old and the new name.
See
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/
The test is currently passing everywhere but this 32-bit arm ubuntu bot.
I don't have an easy way to debug this, so I'm skipping the test on that
platform till we get a chance to figure this out.
The computation of 'Thread::IsVirtualStep" was wrong - it called being
at the bottom of a virtual call stack a "virtual step" but that is
actually when you've gotten to concrete code and need to step for real.
I also added a test for this.
This fixes the two test suite failures that I missed in the PR:
https://github.com/llvm/llvm-project/pull/112939
One was a poorly written test case - it assumed that on connect to a
gdb-remote with a running process, lldb MUST have fetched all the frame
0 registers. In fact, there's no need for it to do so (as the CallSite
patch showed...) and if we don't need to we shouldn't. So I fixed the
test to only expect a `g` packet AFTER calling read_registers.
The other was a place where some code had used 0 when it meant
LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where
it was still compared to 0.
The tests were using the variable directly to get the dwarf version used
for the test. That's only the overridden value, and won't be set if
we're using the compiler default. I also put a comment by the variable
to make sure people don't make the same mistake in the future.
When `FileAction` opens file with write access, it doesn't clear the
file nor append to the end of the file if it already exists. Instead, it
writes from cursor index 0.
For example, by using the settings `target.output-path` and
`target.error-path`, lldb will redirect process stdout/stderr to files.
It then calls this function to write to the files which the above
symptoms appear.
## Test
- Added unit test checking the file flags
- Added 2 api tests checking
- File content overwritten if the file path already exists
- Stdout and stderr redirection to the same file doesn't change its
behavior
…ne stepping (#112939)"
This was breaking some gdb-remote packet counting tests on the bots. I
can't see how this patch could cause that breakage, but I'm reverting to
figure that out.
This reverts commit f147437945.
