Currently in some cases lldb reports stop reason as "step out" or "step over" (from thread plan completion) instead of "breakpoint", if the user breakpoint happens to be set on the same address.
The part of f08f5c9926 seems to overwrite internal breakpoint detection logic, so that only the last breakpoint for the current stop address is considered.
Together with step-out plans not clearing its breakpoint until they are destrouyed, this creates a situation when there is a user breakpoint set for address, but internal breakpoint makes lldb report a plan completion stop reason instead of breakpoint.
This patch reverts that internal breakpoint detection logic to consider all breakpoints
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D140368
Otherwise we may be inserting a decl into a DeclContext that's not fully defined yet.
This simplifies/removes some clang AST node creation code. Instead, use
clang::printTemplateArgumentList().
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D142413
On systems like ARM, where the non-addressable bits of a pointer
value may be used for metadata (ARMv8.3 pointer authentication, or
Type Byte Ignore), those bits need to be cleared before the address
points to a valid memory location. Add a call to the target's ABI
to clear those from address expression arguments to the lldb
commands (e.g. `disassemble -a`).
Differential Revision: https://reviews.llvm.org/D141629
The SBModule copy constructor has fast execution, and is high firing. Fast and
frequent functions are not good candidates for timers.
Differential Revision: https://reviews.llvm.org/D142150
This is processed by hand in CommandObjectMultiword, and is undiscoverable,
it doesn't work in all cases. Because it is a bare word, it can't really be
extended w/o introducing the possibility of collisions as well. If we did
want to do something like this we should add a --help flag to CommandObject. That
way the feature would be consistent and documented.
Differential Revision: https://reviews.llvm.org/D142067
The remote stub may give lldb hints about binaries to
be loaded, especially in a firmware type environment, and
relay those hints in the qProcessInfo response. The
binary loading was done very early in Process setup, before
we had any threads, and this made it complicated for people
to write dSYM python scripts which need access to a thread.
Delay the binary loading until a bit later in the Process
startup.
Differential Revision: https://reviews.llvm.org/D141972
rdar://104235301
Before:
```
(lldb) expr --language abc -- 1 + 1
error: unknown language type: 'abc' for expression
```
After:
```
(lldb) expr --language abc -- 1 + 1
error: unknown language type: 'abc' for expression. List of supported languages:
c++
objective-c++
c++03
c++11
c++14
objc++
```
We choose to only list the languages which `expr` will actually
accept instead of all the language constants defined in `Language.cpp`
since that's what the user will most likely need.
Differential Revision: https://reviews.llvm.org/D142034
SymbolFiles should own Types by keeping them in their TypeList. This
patch privates the Type constructor to guarantee that every created Type
is kept in the SymbolFile's type list.
Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the
same for `makeMutableArrayRef`.
Once all of the places in-tree are using the deduction guides for
`MutableArrayRef`, we can mark `makeMutableArrayRef` as deprecated.
Differential Revision: https://reviews.llvm.org/D141814
This claims to take a platform name argument but doesn't.
That was probably the intent in fbb7634934
but it has only ever worked with the current platform.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D136928
It seems like these were copied from the single-step code and not
updated to match the new flags.
Differential revision: https://reviews.llvm.org/D141816
Add floating-point branch Instructions for EmulateInstructionLoongArch and
add relevant unit tests.
Without this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.45s
Passed: 1044
```
With this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.20s
Passed: 1048
```
Reviewed By: SixWeining, MaskRay, DavidSpickett
Differential Revision: https://reviews.llvm.org/D140759
In RegisterInfos_loongarch64.h, r22 is defined twice. Having an extra array
member causes problems reading and writing registers defined after r22. So,
for r22, keep the alias fp, delete the s9 alias.
The PC register is incorrectly accessed when the step command is executed.
The step command behavior is incorrect.
This test reflects this problem:
```
loongson@linux:~$ cat test.c
#include <stdio.h>
int func(int a) {
return a + 1;
}
int main(int argc, char const *argv[]) {
func(10);
return 0;
}
loongson@linux:~$ clang -g test.c -o test
```
Without this patch:
```
loongson@linux:~$ llvm-project/llvm/build/bin/lldb test
(lldb) target create "test"
Current executable set to '/home/loongson/test' (loongarch64).
(lldb) b main
Breakpoint 1: where = test`main + 40 at test.c:8:3, address = 0x0000000120000668
(lldb) r
Process 278049 launched: '/home/loongson/test' (loongarch64)
Process 278049 stopped
* thread #1, name = 'test', stop reason = breakpoint 1.1
frame #0: 0x0000000120000668 test`main(argc=1, argv=0x00007fffffff72a8) at test.c:8:3
5 }
6
7 int main(int argc, char const *argv[]) {
-> 8 func(10);
9 return 0;
10 }
11
(lldb) s
Process 278049 stopped
* thread #1, name = 'test', stop reason = step in
frame #0: 0x0000000120000670 test`main(argc=1, argv=0x00007fffffff72a8) at test.c:9:3
6
7 int main(int argc, char const *argv[]) {
8 func(10);
-> 9 return 0;
10 }
```
With this patch:
```
loongson@linux:~$ llvm-project/llvm/build/bin/lldb test
(lldb) target create "test"
Current executable set to '/home/loongson/test' (loongarch64).
(lldb) b main
Breakpoint 1: where = test`main + 40 at test.c:8:3, address = 0x0000000120000668
(lldb) r
Process 278632 launched: '/home/loongson/test' (loongarch64)
Process 278632 stopped
* thread #1, name = 'test', stop reason = breakpoint 1.1
frame #0: 0x0000000120000668 test`main(argc=1, argv=0x00007fffffff72a8) at test.c:8:3
5 }
6
7 int main(int argc, char const *argv[]) {
-> 8 func(10);
9 return 0;
10 }
11
(lldb) s
Process 278632 stopped
* thread #1, name = 'test', stop reason = step in
frame #0: 0x0000000120000624 test`func(a=10) at test.c:4:10
1 #include <stdio.h>
2
3 int func(int a) {
-> 4 return a + 1;
5 }
```
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D140615
Currently default simd alignment is specified by Clang specific TargetInfo
class. This class cannot be reused for LLVM Flang. If we move the default
alignment field into TargetMachine class then we can create TargetMachine
objects and query them to find SIMD alignment.
Scope of changes:
1) Added information about maximal allowed SIMD alignment to TargetMachine
classes.
2) Removed getSimdDefaultAlign function from Clang TargetInfo class.
3) Refactored createTargetMachine function.
Reviewed By: jsjodin
Differential Revision: https://reviews.llvm.org/D138496
RVC is the RISC-V standard compressed instruction-set extension, named "C", which reduces static and dynamic code size by adding short 16-bit instruction encodings for common operations, and RVCD is the compressed "D extension".
And "D extension" is a double-precision floating-point instruction-set extension, which adds double-precision floating-point computational instructions compliant with the IEEE 754-2008 arithmetic standard.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D140961
This patch enhances queue support in Scripted Processes.
Scripted Threads could already report their queue name if they had one,
but this information was only surfaced when getting the process and
thread status.
However, no queue was create and added to the scripted process queue
list. This patch improves that by creating a queue from the scripted
thread queue name. For now, it uses an invalid queue id, since the
scripted thread doesn't expose this capability yet, but this could
easily be supported if the queue id information is available.
rdar://98844004
Differential Revision: https://reviews.llvm.org/D139853
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Add unit tests For EmulateInstructionLoongArch existing branch instruction.
Add 19 test cases in total.
Without this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.55s
Passed: 1025
```
With this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.45s
Passed: 1044
```
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D140386
This adds the jump slot mapping for LoongArch. This is a simple
change that ensures lldb running properly.
Note that this problem was found only when CMake variables
"DLLVM_ENABLE_ASSERTIONS=ON" is selected.
Without this patch,
```
$ build/bin/lldb test
../ELFHeader::GetRelocationJumpSlotType() const: Assertion `false && "architecture not supported"' fail
```
With this patch
```
$ build/bin/lldb test
(lldb) target create "test"
Current executable set to '../test' (loongarch64).
```
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D141245
This patch introduces both the ScriptedPlatformInterface and the
ScriptedPlatformPythonInterface. As the name suggests, these calls will
be used to call into the Scripted Platform python implementation from
the C++ Scripted Platform plugin instance.
Differential Revision: https://reviews.llvm.org/D139251
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces both the Scripted Platform python base
implementation and an example for it.
The base implementation is embedded in lldb python module under
`lldb.plugins.scripted_platform`.
This patch also refactor the various SWIG methods to create scripted
objects into a single method, that is now shared between the Scripted
Platform, Process and Thread. It also replaces the target argument by a
execution context object.
Differential Revision: https://reviews.llvm.org/D139250
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is preparatory work for Scripted Platform support and does
multiple things:
First, it introduces new options for the `platform select` command and
`SBPlatform::Create` API, to hold a reference to the debugger object,
the name of the python script managing the Scripted Platform and a
structured data dictionary that the user can use to pass arbitrary data.
Then, it updates the various `Create` and `GetOrCreate` methods for
the `Platform` and `PlatformList` classes to pass down the new parameter
to the `Platform::CreateInstance` callbacks.
Finally, it updates every callback to reflect these changes.
Differential Revision: https://reviews.llvm.org/D139249
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch makes `ScriptedPythonInterface::GetStatusFromMethod` take a
parameter pack as an argument. That will allow it to pass arbitrary
arguments to the python method.
Differential Revision: https://reviews.llvm.org/D139248
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch moves the ScriptedProcessInfo class out of the
ScriptedProcess and hoist it as a standalone interpreter class, so it can be
reused with the Scripted Platform.
Differential Revision: https://reviews.llvm.org/D139247
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This regressed with `e262b8f48af9fdca8380f2f079e50291956aad71`.
Two issues here:
1. `:16x` is not a valid format specifier and
we would crash when we encountered this log
(which was the case in `TestCPPAccelerator.py`)
2. The third argument was missing curly braces so
the log message itself was malformed.
Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D139379
After an exec has occured, resources used to manage the state of a
Process are cleaned up. One such resource is the AllocatedMemoryCache
which keeps track of memory allocations made in the process for things
like expression evaluation. After an exec is performed, the allocated
memory regions in the process are gone, so it does not make sense to try
to deallocate those regions.
rdar://103188106
Differential Revision: https://reviews.llvm.org/D140249
The Xcode standalone build doesn't have the install-liblldb and
install-liblldb-stripped targets. Fix the resulting CMake error "Cannot
add target-level dependencies to non-existent target" by only adding the
dependency when the targets exist.
CMake supports building Framework bundles for Apple platforms. We rely
on this functionality to create LLDB.framework. From CMake's
perspective, a framework is associated with a single target. In reality,
this is often not the case. In addition to a main library (liblldb) the
frameworks often contains associated resources that are their own CMake
targets, such as debugserver and lldb-argdumper.
When building and using the framework to run the test suite, those
binaries are expected to be in LLDB.framework. We have a function
(lldb_add_to_buildtree_lldb_framework) that copies those targets into
the framework.
When CMake installs a framework, it copies over the content of the
framework directory and "installs" the associated target. In addition to
copying the target, installing also means updating the RPATH. However,
the RPATH is only updated for the target associated with the framework.
Everything else is naively copied over, including executables or
libraries that have a different build and install RPATH. This means that
those tools need to have their own install rules.
If the framework is installed first, the aforementioned tools are copied
over with build RPATHs from the build tree. And when the tools
themselves are installed, the binaries get overwritten and the RPATHs
updated to the install RPATHs.
The problem is that CMake provides no guarantees when it comes to the
order in which components get installed. If those tools get installed
first, the inverse happens and the binaries get overwritten with the
ones that have build RPATHs.
lldb_add_to_buildtree_lldb_framework has a comment correctly stating
that those copied binaries should be removed before install. This patch
adds a custom target (lldb-framework-cleanup) that will be run before
the install phase and remove those files from LLDB.framework in the
build tree.
Differential revision: https://reviews.llvm.org/D141021
Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D139379
The current interface theoretically could lead to a use-after-free
when a client holds on to the returned pointer. Fix this by returning
a shared_ptr to the scratch typesystem.
rdar://103619233
Differential Revision: https://reviews.llvm.org/D141100
When ingesting aranges from a dSYM, always trust the contents of the
accelerator table since it always comes from dsymutil.
According to Instruments, skipping the decoding of all CU DIEs to get at
the DW_AT_ranges attribute removes ~3.5 seconds from setting a
breakpoint by file/line when debugging clang with a dSYM. Interestingly
on the wall clock the speedup is less noticeable, but still present.
rdar://problem/56057688
Differential Revision: https://reviews.llvm.org/D68655
In preparation for eanbling 64bit support in LLDB switching to use llvm::formatv
instead of format MACROs.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D139955
The symbol file stores a raw pointer to the main object file's symbol
table. This pointer, however, can be freed, if ObjectFile::ClearSymtab
is ever called. This patch makes sure out pointer to the symbol file
is valid before using it.
