LLDB can crash in TypeSystemClang::GetIndexOfChildMemberWithName, at a
point where it pushes an index onto the child_indexes vector, tries to
call itself recursively, then tries to pop the entry from child_indexes.
The problem is that the recursive call can clear child_indexes, so that
this code ends up trying to pop an already empty vector. This change
saves the old vector before the push, then restores the saved vector
rather than trying to pop.
Specify ENABLE_THREADS := YES within test's Makefile instead of passing
-lpthread explicitly via the compiler's CFLAGS options.
Refactoring fix.
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
This PR fixes a simple SWIG issue with SBMemoryRegionInfoList not being
iterable out-of-the-box. This is mostly because of limitations to the
`lldb_iter` function, which doesn't allow for specifying arguments to
the size / iter functions passed.
Before:
```
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> for region in lldb.process.GetMemoryRegions():
... print(region)
...
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/opt/llvm/stable/Toolchains/llvm-sand.xctoolchain/usr/lib/python3.10/site-packages/lldb/__init__.py", line 114, in lldb_iter
yield elem(i)
TypeError: SBMemoryRegionInfoList.GetMemoryRegionAtIndex() missing 1 required positional argument: 'region_info'
```
After:
```
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> for region in lldb.process.GetMemoryRegions():
... print(region)
...
[0x0000000000200000-0x00000000002cf000 R--]
[0x00000000002cf000-0x0000000000597000 R-X]
[0x0000000000597000-0x00000000005ad000 R--]
[0x00000000005ad000-0x00000000005b1000 RW-]
[0x00000000005b1000-0x0000000000b68000 RW-]
[0x000000007fff7000-0x000000008fff7000 RW-]
[0x000002008fff7000-0x000010007fff8000 RW-]
[0x0000503000000000-0x0000503000010000 RW-]
[0x0000503e00000000-0x0000503e00010000 RW-]
[0x0000504000000000-0x0000504000010000 RW-]
[0x0000504e00000000-0x0000504e00010000 RW-]
[0x000050d000000000-0x000050d000010000 RW-]
[0x000050de00000000-0x000050de00010000 RW-]
[0x000050e000000000-0x000050e000010000 RW-]
[0x000050ee00000000-0x000050ee00010000 RW-]
[0x0000511000000000-0x0000511000010000 RW-]
[0x0000511e00000000-0x0000511e00010000 RW-]
[0x0000513000000000-0x0000513000010000 RW-]
...
```
`frame variable` supports nested variable access, which the API calls "variable
expression paths". This change updates `dwim-print` to support a subset of supported
variable expression paths.
Consider the expression `a->b`. In C++, the arrow operator can be overloaded, and where
that is the case, expression evaluation must be used to evaluate it, not frame variable.
Likewise, the subscript operator can be overloaded.
To avoid those cases, this change introduces a limited support for variable expression
paths. Use of the dot operator is allowed.
Additionally, this change allows `dwim-print` to directly access children of `this` and
`self` (see AllowDirectIVarAccess). This functionality is also provided by the same
`GetValueForVariableExpressionPath` method.
rdar://104348908
The old behavior was to return a null string in the error case,when
refactoring the error handling I thought it would be a good idea to
print the error in the description, but that breaks clients that try to
print a description first and then do something else in the error case.
The API is not great but it's clear that in-band errors are also not a
good idea.
rdar://133956263
Prior to this patch, the function returned an exit status, sometimes a
ValueObject with an error and a Status object. This patch removes the
Status object and ensures the error is consistently returned as the
error of the ValueObject.
This fixes a functionality gap with GDB, where GDB will properly decode
the stop reason and give the address for SIGSEGV. I also added
descriptions to all stop reasons, following the same code path that the
Native Linux Thread uses.
This is motivated by exposing some Swift language-specific flags through
the API, in the example here it is used to communicate the Objective-C
runtime version. This could also be a meaningful extension point to get
information about "embedded: languages, such as extracting the C++
version in an Objective-C++ frame or something along those lines.
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.
