This test was timing out on Linaro's Windows on Arm bot.
This was because it couldn't identify an inlined function to
break on, which let it run into an infinite loop, which exhausted
the stack, which would have taken forever to backtrace.
Full details here - https://github.com/llvm/llvm-project/issues/143104
I'm not sure PDB would help here but it does work with DWARF
as long as we use a linker that keeps it.
So I've changed the test to require Windows and lld, unless you're
not on Windows and then you can use any linker.
Also I had to regex some parts of the function name because
on Windows we get the return and parameter types too.
This was removed in https://github.com/llvm/llvm-project/pull/135343 in
favour of making it a format variable, which we do here. This follows
the precedent of the `[opt]` and `[artificial]` markers.
Before:
```
thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3
frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17
frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43
frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3
frame #4: 0x0000000186345be4 dyld`start + 7040
```
After (note the `[inlined]` markers):
```
thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3 [inlined]
frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17
frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43 [inlined]
frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3
frame #4: 0x0000000186345be4 dyld`start + 7040
```
rdar://152642178
This commit creates a Python script that fixes up the versioning
information in lldb-defines.h. It also moves the build logic for fixing
up the lldb headers from being in the framework only to being in the
same location that we create the liblldb target.
Failing on the Linux bots with:
```
+ /home/worker/2.0.1/lldb-x86_64-debian/build/bin/FileCheck /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/Shell/Expr/TestClangModulesDeclLookup.test
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/Shell/Expr/TestClangModulesDeclLookup.test:56:15: error: CHECK-NEXT: expected string not found in input
^
<stdin>:38:26: note: scanning from here
(lldb) expression foo(50)
^
<stdin>:41:34: note: possible intended match here
(lldb) target modules dump ast --filter foo
^
```
Adds coverage for the code-path where
`ClangExpressionDeclMap::FindExternalVisibleDecls` finds a decl inside
of a Clang module (without explicitly having to import the module on the
LLDB CLI). AFAICT, we had not tests for this.
`LookupFunction` will try to find a `FunctionDecl` in debug-info. But if
no debug-info exists, it will ask the `ClangModulesDeclVendor` to search
for the function with the specified name in any of the Clang modules
that got added to it in `SetupDeclVendor`.
Again I think this requires DWARF. In theory we could use the PDB
file but I suspect that PDB file is in fact empty, because we
tell clang to produce DWARF.
So on Windows, first thing is we cannot run the expressions:
(lldb) expr A(); A1(); BA1(); AB();
error: <user expression 1>:1:1: 'A' has unknown return type; cast the call to its declared return type
1 | A(); A1(); BA1(); AB();
| ^~~
...and so on...
And then the AST is all unknown functions:
(lldb) image dump ast
Dumping clang ast for 4 modules.
TranslationUnitDecl 0x2b3bb591870 <<invalid sloc>> <invalid sloc> <undeserialized declarations>
|-FunctionDecl 0x2b3bb592970 <<invalid sloc>> <invalid sloc> mainCRTStartup 'unsigned long (void *)'
| `-ParmVarDecl 0x2b3bb592a20 <<invalid sloc>> <invalid sloc> 'void *'
`-FunctionDecl 0x2b3bb592ad8 <<invalid sloc>> <invalid sloc> __scrt_common_main_seh 'int ()' static
So I'm just going to disable this test on Windows, it's pretty
clear why it doesn't work and we have no plans to make it work.
Depends on https://github.com/llvm/llvm-project/pull/142163
This patch makes the `-ast-dump-filter` Clang option available to the
`target modules dump ast` command. This allows us to selectively dump
parts of the AST by name.
The AST can quickly grow way too large to skim on the console. This will
aid in debugging AST related issues.
Example:
```
(lldb) target modules dump ast --filter func
Dumping clang ast for 48 modules.
Dumping func:
FunctionDecl 0xc4b785008 <<invalid sloc>> <invalid sloc> func 'void (int)' extern
|-ParmVarDecl 0xc4b7853d8 <<invalid sloc>> <invalid sloc> x 'int'
`-AsmLabelAttr 0xc4b785358 <<invalid sloc>> Implicit "_Z4funcIiEvT_"
Dumping func<int>:
FunctionDecl 0xc4b7850b8 <<invalid sloc>> <invalid sloc> func<int> 'void (int)' implicit_instantiation extern
|-TemplateArgument type 'int'
| `-BuiltinType 0xc4b85b110 'int'
`-ParmVarDecl 0xc4b7853d8 <<invalid sloc>> <invalid sloc> x 'int'
```
The majority of this patch is adjust the `Dump` API. The main change in
behaviour is in `TypeSystemClang::Dump`, where we now use the
`ASTPrinter` for dumping the `TranslationUnitDecl`. This is where the
`-ast-dump-filter` functionality lives in Clang.
Despite a great review from @labath, I accidentally landed the signal
with the UID and PID properties flipped. I was actually trying to write
tests for this feature when I discovered it.
This fixes that bug, and add a shell test that runs only on Nix systems.
When inspecting/printing types from MSVC's STL, LLDB would crash because
it assumes these types were from libstdc++. Specifically,
`std::shared_ptr` and `std::optional` would crash because of a null
pointer dereference. I added a minimal test that tests the types with
C++ helpers for libstdc++ (only tests for crashes).
- Fixes#115216
- Fixes#120310
This still has one unresolved discussion: What about MS STL types? This
is https://github.com/llvm/llvm-project/issues/24834, but there was a
bit of discussion in #120310 as well. The main issue is that MSVC's STL
uses the same type names as libstdc++ (i.e. neither uses an inline
namespace like libc++ for some types).
From https://github.com/llvm/llvm-project/pull/140761. `MsvcBuilder`
passed `/std:<value>` (if specified) after `--`, so the compiler would
interpret this as a file. This moves the argument before the `--`.
This PR is a subset of the commits made in
https://github.com/swiftlang/llvm-project/pull/10710.
The most notable change is the addition of `PrefixRange` and
`SuffixRange` which are a catch-all to track anything after or before a
function's demangled name. In the case of Swift, this allows to add
support for name highlighting without having to track the range of the
scope and specifiers of a function (this will come in another PR).
* Changes the default synthetic symbol names to contain their file
address
This is a new PR after the first PR (#137512) was reverted because it
didn't update the way unnamed symbols were searched in the symbol table,
which relied on the index being in the name.
This time also added extra test to make sure the symbol is found as
expected
similar to #140570
getting this error:
exit status 1
ld.lld: error: section '.text' address (0x8074) is smaller than image
base (0x10000); specify --image-base
Given this simple test case:
```
// foo.h
extern int* ptr;
inline void g(int x) {
*ptr = x; // should raise a SIGILL
}
//--------------
// foo.cc
#include "foo.h"
int* ptr;
//--------------
// main.cc
#include "foo.h"
int main() {
g(123); // Call the inlined function and crash
return 0;
}
$ clang -g main.cc foo.cc -o main.out
$ lldb main.out
```
When you run `main.out` under lldb, it'd stop inside `void g(int)`
because of the crash.
The stack trace would show that it had crashed in `foo.h`, but if you do
`list foo.h:2`, lldb would complain that it could not find the source
file, which is confusing.
This patch make `list` work with headers.
AddressFunctionScope was always returning the first address range of the
function (assuming it was the only one). This doesn't work for
RegisterContextUnwind (it's only caller), when the function doesn't
start at the lowest address because it throws off the 'how many bytes
"into" a function I am' computation. This patch replaces the result with
a call to (recently introduced)
SymbolContext::GetFunctionOrSymbolAddress.
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
Continuing the theme from #116777 and #124931, this patch ensures we
compute the correct address when a functions is spread across multiple
sections. Due to this, it's not sufficient to adjust the offset in the
section+offset pair (Address::Slide). We must actually slide the file
offset and then recompute the section using the result.
I found this out due to a failure to disassemble some parts of the
function, so I'm testing with that, although it's likely there are other
things that were broken due to this.
This reverts commit daa4061d61216456baa83ab404e096200e327fb4.
Original PR https://github.com/llvm/llvm-project/pull/129092.
I have restricted the test to X86 Windows because it turns out the only
reason that `expr x.get()` would change m_memory_id is that on x86 we
have to write the return address to the stack in ABIWindows_X86_64::PrepareTrivialCall:
```
// Save return address onto the stack
if (!process_sp->WritePointerToMemory(sp, return_addr, error))
return false;
```
This is not required on AArch64 so m_memory_id was not changed:
```
(lldb) expr x.get()
(int) $0 = 0
(lldb) process status -d
Process 15316 stopped
* thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff764a31034
frame #0: 0x00007ff764a31038 TestProcessModificationIdOnExpr.cpp.tmp`main at TestProcessModificationIdOnExpr.cpp:35
32 __builtin_debugtrap();
33 __builtin_debugtrap();
34 return 0;
-> 35 }
36
37 // CHECK-LABEL: process status -d
38 // CHECK: m_stop_id: 2
ProcessModID:
m_stop_id: 3
m_last_natural_stop_id: 0
m_resume_id: 0
m_memory_id: 0
```
Really we should find a better way to force a memory write here, but
I can't think of one right now.
And a follow up warning fix.
This reverts commit 6aa963f780d63d4c8fa80de97dd79c932bc35f4e
and 2bff80f25d51e24d3c552e033a2863dd36ef648b.
This is failing on Windows on Arm: https://lab.llvm.org/buildbot/#/builders/141/builds/8375
Seems to produce the line the test wants but not in the right place.
Reverting while I investigate.
This change adds a setting `target.process.track-memory-cache-changes`.
Disabling this setting prevents invalidating and updating values in
`ValueObject::UpdateValueIfNeeded` when only "internal" debugger memory
is updated. Writing to "internal" debugger memory happens when, for
instance, expressions are evaluated by visualizers (pretty printers).
One of the examples when cache invalidation has a particularly heavy
impact is visualizations of some collections: in some collections
getting collection size is an expensive operation (it requires traversal
of the collection).
At the same time evaluating user expression with side effects (visible
to target, not only to debugger) will still bump memory ID because:
- If expression is evaluated via interpreter: it will cause write to
"non-internal" memory
- If expression is JIT-compiled: then to call the function LLDB will
write to "non-internal" stack memory
The downside of disabled `target.process.track-memory-cache-changes`
setting is that convenience variables won't reevaluate synthetic
children automatically.
---------
Co-authored-by: Mikhail Zakharov <mikhail.zakharov@jetbrains.com>
We want to be able to access the Clang resources directory in LLDB shell
tests, this commit adds the ability to do this by populating the
`CLANG_RESOURCE_DIR` variable in LLDBConfig.cmake.
We skip/xfail the other FrameFormat tests on Windows already. The number
of different buildbot configurations out there targetting Windows makes
it hard to make this test portable. If we want to test this on Windows
we should probably just make a dedicated test for it.
This patch adds another frame-format variable (currently only
implemented in the CPlusPlus language plugin) that represents the
"suffix" of a function. The name is derived from the `DotSuffix` node of
LLVM's Itanium demangler.
For a function name such as `int foo() (.cold)`, the suffix would be
`(.cold)`.
Reverts llvm/llvm-project#137408
This change broke `lldb/test/Shell/Unwind/split-machine-functions.test`.
The test binary has a symbol named `_Z3foov.cold` and the test expects
the backtrace to print the name of the cold part of the function like
this:
```
# SPLIT: frame #1: {{.*}}`foo() (.cold) +
```
but now it gets
```
frame #1: 0x000055555555514f split-machine-functions.test.tmp`foo() + 12
```
This patch makes the frame-format variables introduced in
https://github.com/llvm/llvm-project/pull/131836 also work when no
debug-info is available. Previously, we assumed `sc.function` was
available, but without debug-info we might only have `sc.symbol`. We
don't really need the `sc.function` apart from when formatting
arguments.
For the function arguments case I added a fallback that will just print
the arguments we get from the demangler (which is what LLDB does for
stacktraces with no debug-info anyway). Ideally we'd have a separate
`FormatEntity::Entry::Type::FunctionArguments` that will just print the
arguments from the demangler and have something like the following in
the `plugin.cplusplus.display.function-name-format`:
```
{ ${function.formatted-arguments} || ${function.arguments} }
```
I.e., when we can't format the arguments, print the ones from the
demangler. But we currently don't have the `||` operator in the
frame-format language yet.
Without this for some reason Linux PR CI was failing with:
```
(lldb) settings set -f frame-format "custom-frame '${function.basename}'\n"
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:50'1 ? possible intended match
9: (lldb) break set -l 5 -f main.cpp
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10: Breakpoint 1: no locations (pending).
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
11: WARNING: Unable to resolve breakpoint to any actual locations.
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Try to work around following error on some of the Linux CI:
```
8: (lldb) settings set -f frame-format "custom-frame '${function.basename}'\n"
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:50'1 ? possible intended match
9: (lldb) break set -l 5
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~
10: error: No selected frame to use to find the default file.
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
11: error: No file supplied and no default file available.
check:50'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
12: (lldb) exit
check:50'0 ~~~~~~~~~~~~
```
Fails on Windows CI:
```
| 10: (lldb) break set -l 3
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~
| 11: error: No selected frame to use to find the default file.
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 12: error: No file supplied and no default file available.
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 13: (lldb) exit
```
This passes fine when compiling on Windows for Linux targets.
