This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110216
[NFC] This patch replaces master and slave with primary and secondary
respectively when referring to pseudoterminals/file descriptors.
Reviewed By: clayborg, teemperor
Differential Revision: https://reviews.llvm.org/D113687
When LLDB receives a SIGINT while running the embedded Python REPL it currently
just crashes in `ScriptInterpreterPythonImpl::Interrupt` with an error such as
the one below:
```
Fatal Python error: PyThreadState_Get: the function must be called with the GIL
held, but the GIL is released (the current Python thread state is NULL)
```
The faulty code that causes this error is this part of `ScriptInterpreterPythonImpl::Interrupt`:
```
PyThreadState *state = PyThreadState_GET();
if (!state)
state = GetThreadState();
if (state) {
long tid = state->thread_id;
PyThreadState_Swap(state);
int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);
```
The obvious fix I tried is to just acquire the GIL before this code is running
which fixes the crash but the `KeyboardInterrupt` we want to raise immediately
is actually just queued and would only be raised once the next line of input has
been parsed (which e.g. won't interrupt Python code that is currently waiting on
a timer or IO from what I can see). Also none of the functions we call here is
marked as safe to be called from a signal handler from what I can see, so we
might still end up crashing here with some bad timing.
Python 3.2 introduced `PyErr_SetInterrupt` to solve this and the function takes
care of all the details and avoids doing anything that isn't safe to do inside a
signal handler. The only thing we need to do is to manually setup our own fake
SIGINT handler that behaves the same way as the standalone Python REPL signal
handler (which raises a KeyboardInterrupt).
From what I understand the old code used to work with Python 2 so I kept the old
code around until we officially drop support for Python 2.
There is a small gap here with Python 3.0->3.1 where we might still be crashing,
but those versions have reached their EOL more than a decade ago so I think we
don't need to bother about them.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D104886
This adds a specific unwind plan for AArch64 Linux sigreturn frames.
Previously we assumed that the fp would be valid here but it is not.
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso/sigreturn.S
On Ubuntu Bionic it happened to point to an old frame info which meant
you got what looked like a correct backtrace. On Focal, the info is
completely invalid. (probably due to some code shuffling in libc)
This adds an UnwindPlan that knows that the sp in a sigreturn frame
points to an rt_sigframe from which we can offset to get saved
sp and pc values to backtrace correctly.
Based on LibUnwind's change: https://reviews.llvm.org/D90898
A new test is added that sets all compares the frames from the initial
signal catch to the handler break. Ensuring that the stack/frame pointer,
function name and register values match.
(this test is AArch64 Linux specific because it's the only one
with a specific unwind plan for this situation)
Fixes https://bugs.llvm.org/show_bug.cgi?id=52165
Reviewed By: omjavaid, labath
Differential Revision: https://reviews.llvm.org/D112069
D112976 moved most of the guts of __vector_base into vector, this broke
some LLDB tests by changing the result types that LLDB sees. This updates
the test to reflect the new structure.
Teach LLDB to understand INLINE and INLINE_ORIGIN records in breakpad.
They have the following formats:
```
INLINE inline_nest_level call_site_line call_site_file_num origin_num [address size]+
INLINE_ORIGIN origin_num name
```
`INLNIE_ORIGIN` is simply a string pool for INLINE so that we won't have
duplicated names for inlined functions and can show up anywhere in the symbol
file.
`INLINE` follows immediately after `FUNC` represents the ranges of momery
address that has functions inlined inside the function.
Differential Revision: https://reviews.llvm.org/D113330
Because TestScriptedProcess.py creates a skinny corefile to provides data
to the ScriptedProcess and ScriptedThread, we need to make sure that the
debugserver used is not out of tree, to ensure feature availability
between debugserver and lldb.
This also removes the `SKIP_SCRIPTED_PROCESS_LAUNCH` env variable after
each test finish running.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Since every FUNC record (in breakpad) is a compilation unit, creating the
function for the CU allows `ResolveSymbolContext` to resolve
`eSymbolContextFunction`.
Differential Revision: https://reviews.llvm.org/D113163
This reverts commit 3bf96b0329.
It causes crashes as reported in PR52257 and a few other places. A reproducer is bundled with this commit to verify any fix forward. The original test is left in place, but marked XFAIL as it now produces the wrong result.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D113449
It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing. I'm
currently resorting to convolutions like this:
def find_lldb(may_reexec=False):
if prefix := os.environ.get('LLDB_PYTHON_PREFIX'):
if os.path.realpath(prefix) != os.path.realpath(sys.prefix):
raise Exception("cannot import lldb.\n"
f" sys.prefix should be: {prefix}\n"
f" but it is: {sys.prefix}")
else:
line1, line2 = subprocess.run(
['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'],
encoding='utf8', stdout=subprocess.PIPE,
check=True).stdout.strip().splitlines()
assert line1.strip() == '(lldb) script print(sys.prefix)'
prefix = line2.strip()
os.environ['LLDB_PYTHON_PREFIX'] = prefix
if sys.prefix != prefix:
if not may_reexec:
raise Exception(
"cannot import lldb.\n" +
f" This python, at {sys.prefix}\n"
f" does not math LLDB's python at {prefix}")
os.environ['LLDB_PYTHON_PREFIX'] = prefix
python_exe = os.path.join(prefix, 'bin', 'python3')
os.execl(python_exe, python_exe, *sys.argv)
lldb_path = subprocess.run(['lldb', '-P'],
check=True, stdout=subprocess.PIPE,
encoding='utf8').stdout.strip()
sys.path = [lldb_path] + sys.path
This patch aims to replace all that with:
#!/usr/bin/env lldb-python
import lldb
...
... by adding the following features:
* new command line option: --print-script-interpreter-info. This
prints language-specific information about the script interpreter
in JSON format.
* new tool (unix only): lldb-python which finds python and exec's it.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112973
This patch changes the ScriptedProcess test to use a stack-only skinny
corefile as a backing store.
The corefile is saved as a temporary file at the beginning of the test,
and a second target is created for the ScriptedProcess. To do so, we use
the SBAPI from the ScriptedProcess' python script to interact with the
corefile process.
This patch also makes some small adjustments to the other ScriptedProcess
scripts to resolve some inconsistencies and removes the raw memory dump
that was previously checked in.
Differential Revision: https://reviews.llvm.org/D112047
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes the `ScriptedThread` initializer in couple of ways:
- It replaces the `SBTarget` parameter by a `SBProcess` (pointing to the
`ScriptedProcess` that "owns" the `ScriptedThread`).
- It adds a reference to the `ScriptedProcessInfo` Dictionary, to pass
arbitrary user-input to the `ScriptedThread`.
This patch also fixes the SWIG bindings methods that call the
`ScriptedProcess` and `ScriptedThread` initializers by passing all the
arguments to the appropriate `PythonCallable` object.
Differential Revision: https://reviews.llvm.org/D112046
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
GDB and LLDB use different signal models. GDB uses a predefined set
of signal codes, and maps platform's signos to them. On the other hand,
LLDB has historically simply passed native signos.
In order to improve compatibility between LLDB and gdbserver, the GDB
signal model should be used. However, GDB does not provide a mapping
for all existing signals on Linux and unsupported signals are passed
as 'unknown'. Limiting LLDB to this behavior could be considered
a regression.
To get the best of both worlds, use the LLDB signal model when talking
to lldb-server, and the GDB signal model otherwise. For this purpose,
new versions of lldb-server indicate "native-signals+" via qSupported.
At the same time, we also detect older versions of lldb-server
via QThreadSuffixSupported for backwards compatibility. If neither test
succeeds, we assume gdbserver or another implementation using GDB model.
Differential Revision: https://reviews.llvm.org/D108078
This diff adds a data formatter for libstdcpp's forward_list. Besides, it refactors the existing code by extracting the common functionality between libstdcpp forward_list and list formatters into the AbstractListSynthProvider class.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D113362
The Swift stdlib uses absolute symbols in the dylib to communicate
feature flags to the process. LLDB's expression evaluator needs to be
able to find them. This wires up absolute symbols so they show up in
the symtab lookup command, which is also all that's needed for them to
be visible to the expression evaluator JIT.
rdar://85093828
Differential Revision: https://reviews.llvm.org/D113445
Scopes can have an optional hint for how to present this scope in the UI:
https://microsoft.github.io/debug-adapter-protocol/specification#Types_Scope
The IDEs can use the hint to present the data accordingly. For example,
Visual Studio has a separate Registers window, which is populated with the
data from the scope with `presentationHint: "registers"`.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D113400
This patch fixes an amusing bug where a Platform::Kill operation would
happily terminate a proces on a completely different platform, as long
as they have the same process ID. This was due to the fact that the
implementation was iterating through all known (debugged) processes in
order terminate them directly.
This patch just deletes that logic, and makes everything go through the
OS process termination APIs. While it would be possible to fix the logic
to check for a platform match, it seemed to me that the implementation
was being too smart for its own good -- accessing random Process
objects without knowing anything about their state is risky at best.
Going through the os ensures we avoid any races.
I also "upgrade" the termination signal to a SIGKILL to ensure the
process really dies after this operation.
Differential Revision: https://reviews.llvm.org/D113184
Don't try to get a class descriptor for a pointer that doesn't look like
a tagged pointer. Also print addresses as fixed-width hex and update the
test.
LIT skips various system environment variables while building test
config. It turns out that we require PLATFORM environment variable for
detection of x86 vs Arm windows platform.
This patch adds system environment variable PLATFORM into LIT test
config for detection of win32 Arm platform.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D113165
In 7f01f78593 [lldb] update TestEchoCommands -- I fixed this test,
but not on windows, becuase I used some unix shell syntax that
doesn't work with cmd.exe. Fixed it so it will work in both.
Test logic is the same.
This is a trivial fix, so bypassing review to get the build clean again
ASAP.
- Use formatv to print the addresses.
- Add check for 0x0 which is treated as an invalid address.
- Use a an address that's less likely to be interpreted as a real
tagged pointer.
This reverts commit 5fbcf67734.
ProcessDebugger is used in ProcessWindows and NativeProcessWindows.
I thought I was simplifying things by renaming to DoGetMemoryRegionInfo
in ProcessDebugger but the Native process side expects "GetMemoryRegionInfo".
Follow the pattern that WriteMemory uses. So:
* ProcessWindows::DoGetMemoryRegioninfo calls ProcessDebugger::GetMemoryRegionInfo
* NativeProcessWindows::GetMemoryRegionInfo does the same
On AArch64 we have various things using the non address bits
of pointers. This means when you lookup their containing region
you won't find it if you don't remove them.
This changes Process GetMemoryRegionInfo to a non virtual method
that uses the current ABI plugin to remove those bits. Then it
calls DoGetMemoryRegionInfo.
That function does the actual work and is virtual to be overriden
by Process implementations.
A test case is added that runs on AArch64 Linux using the top
byte ignore feature.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D102757
Followup to https://reviews.llvm.org/D112988
Sorry, I broke this test. The test was verifying the bad behavior
of --source-quietly that the previous change fixed -- namely that
it still echos the initial list of startup commands while
sourcing them.
Updated the test to verify that --source-quietly is quiet, rather than
loud.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D113047
Improve error handling for the lang objc tagged-pointer info. Rather
than failing silently, report an error if we couldn't convert an
argument to an address or resolve the class descriptor.
(lldb) lang objc tagged-pointer info 0xbb6404c47a587764
error: could not get class descriptor for 0xbb6404c47a587764
(lldb) lang objc tagged-pointer info n1
error: could not convert 'n1' to a valid address
Differential revision: https://reviews.llvm.org/D112945
Jim says:
lldb has a -Q or --source-quietly option, which supposedly does:
--source-quietly Tells the debugger to execute this one-line lldb command before any file has been loaded.
That seems like a weird description, since we don't generally use source for one line entries, but anyway, let's try it:
> $LLDB_LLVM/clean-mono/build/Debug/bin/lldb -Q "script print('I should be quiet')" a.out -O "script print('I should be before')" -o "script print('I should be after')"
(lldb) script print('I should be before')
I should be before
(lldb) target create "script print('I should be quiet')"
error: unable to find executable for 'script print('I should be quiet')'
That was weird. The first real -O gets sourced but not quietly, then the argument to the -Q gets treated as the target.
> $LLDB_LLVM/clean-mono/build/Debug/bin/lldb -Q a.out -O "script print('I should be before')" -o "script print('I should be after')"
(lldb) script print('I should be before')
I should be before
(lldb) target create "a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) script print('I should be after')
I should be after
Well, that's a little better, but the -Q option seems to have done nothing.
---
This fixes the description of --source-quietly, as well as causing it
to actually suppress echoing while executing the initialization
commands.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D112988
Same reason as in 548dbfaf447cc5fdfc26d34e60e3da08eb609531 -> macOS has a
struct called 'Point' in the libc module. Just remove the redundant includes
here.
Now that passing libcxx via LLVM_ENABLE_PROJECTS has been deprecated,
update the error message and recommend using LLVM_ENABLE_RUNTIMES
instead. This patch also remove the error message for the old layout.
Differential revision: https://reviews.llvm.org/D112856
SetSourceMapFromArguments is called after the core is loaded. This means
that the source file for the crashing code won't have the source map applied.
Move the call to SetSourceMapFromArguments in request_attach to just after
the call to RunInitCommands, matching request_launch behavior.
Reviewed By: clayborg, wallace
Differential Revision: https://reviews.llvm.org/D112834
This diff adds a data formatter for libstdcpp's multiset. Besides, it improves and unifies the tests for multiset for libcxx and libstdcpp for maintainability.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D112785
This diff adds a data formatter for libstdcpp's multimap. Besides, it improves and unifies the tests for multimap for libcxx and libstdcpp for maintainability.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D112752
Currently calling SBType::IsTypeComplete returns true for record types if and
only if the underlying record in our internal Clang AST has a definition.
The function however doesn't actually force the loading of any external
definition from debug info, so it currently can return false even if the type is
actually defined in a program's debug info but LLDB hasn't lazily created the
definition yet.
This patch changes the behaviour to always load the definition first so that
IsTypeComplete now consistently returns true if there is a definition in the
module/target.
The motivation for this patch is twofold:
* The API is now arguably more useful for the user which don't know or care
about the internal lazy loading mechanism of LLDB.
* With D101950 there is no longer a good way to ask a Decl for a definition
without automatically pulling in a definition from the ExternalASTSource. The
current behaviour doesn't seem useful enough to justify the necessary
workarounds to preserve it for a time after D101950.
Note that there was a test that used this API to test lazy loading of debug info
but that has been replaced with TestLazyLoading by now (which just dumps the
internal Clang AST state instead).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D112615
`DWARFASTParserClang::ParseSingleMember` turns DWARF DIEs that describe
struct/class members into their respective Clang representation (e.g.,
clang::FieldDecl). It also updates a record of where the last field
started/ended so that we can speculatively fill any holes between a field and a
bitfield with unnamed bitfield padding.
Right now we are completely ignoring 'artificial' members when parsing the DWARF
of a struct/class. The only artificial member that seems to be emitted in
practice for C/C++ seems to be the vtable pointer.
By completely skipping both the Clang AST node creation and the updating of the
last-field record, we essentially leave a hole in our layout with the size of
our artificial member. If the next member is a bitfield we then speculatively
fill the hole with an unnamed bitfield. During CodeGen Clang inserts an
artificial vtable pointer into the layout again which now occupies the same
offset as the unnamed bitfield. This later brings down Clang's
`CGRecordLowering::insertPadding` when it checks that none of the fields of the
generated record layout overlap.
Note that this is not a Clang bug. We explicitly set the offset of our fields in
LLDB and overwrite whatever Clang makes up.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D112697
Running tests with -t prints all lldb commands being run. It makes sense
to print all the build commands as well.
Differential Revision: https://reviews.llvm.org/D112212
Raphael Isemann