Reworked after several other major changes to the TargetParser since
this was reverted. Combined with several other changes.
Inline calls for the following macros and delete AArch64TargetParser.def:
AARCH64_ARCH, AARCH64_CPU_NAME, AARCH64_CPU_ALIAS, AARCH64_ARCH_EXT_NAME
Squashed changes from D139278 and D139102.
Differential Revision: https://reviews.llvm.org/D138792
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 should fix an nondeterministic error in TestStackCoreScriptedProcess.
In order to test both the multithreading capability and shared library
loading in Scripted Processes, the test would create multiple threads
that would take the same variable as a reference.
The first thread would alter the value and the second thread would
monitor the value until it gets altered. This assumed a certain ordering
regarding the `std::thread` spawning, however the ordering was not
always guaranteed at runtime.
To fix that, the test now makes use of a `std::condition_variable`
shared between the each thread. On the former, it will notify the other
thread when the variable gets initialized or updated and on the latter,
it will wait until the variable it receives a new notification.
This should fix the data racing issue while preserving the testing
coverage.
rdar://98678134
Differential Revision: https://reviews.llvm.org/D139484
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This is a follow-up patch to 6f7835f309b9.
As explained previously, when running from an IDE, it can happen that
the IDE imports some lldb scripts by itself. If the user also tries to
import these commands, lldb will show the following message:
```
error: cannot add command: user command exists and force replace not set
```
This message is confusing to the user, because it suggests that the
command import failed and that the execution should stop. However, in
this case, lldb will continue the execution with the command added
previously by the user.
To prevent that, this patch updates every first-party lldb-packaged
custom commands to override commands that were pre-imported in lldb.
Differential Revision: https://reviews.llvm.org/D140293
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When using interactive crashlog from an IDE, it can happen that the user
already have the `command script import lldb.macosx.crashlog` command on
their `lldbinit` file.
That leads to showing some message:
```
error: cannot add command: user command exists and force replace not set
error: cannot add command: user command exists and force replace not set
```
This leads to confusion because the crashlog symbolication continues and
succeeds even after these errors.
To address that, the crashlog commands get overridden everytime the
script get re-imported.
rdar://103403943
Differential Revision: https://reviews.llvm.org/D140113
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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>
This patch should fix an undefined behaviour that's happening when
parsing a crash report from an IDE. In the previous implementation, the
CrashLogParser base class would use the `__new__` static class method to
create the right parser instance depending on the crash report type.
For some reasons, the derived parser initializer wouldn't be called when
running the command from an IDE, so this patch refactors the
CrashLogParser code to replace the use of the `__new__` method with a
factory `create` static method.
rdar://100527640
Differential Revision: https://reviews.llvm.org/D139951
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>
SWIG allows you to partially disable thread support for a given function
in Python with `nothreadallow`. This functionality is limited to Python,
but until SWIG 4.1, it would silently ignore this for other languages,
such as Lua. New versions of SWIG are more strict and therefore we need
to guard this with `SWIGPYTHON`.
For more details on the functionality, I recommend reading the commit
message from 070a1d562b.
The current doc has people just do "ninja lldb" which is
not incorrect, it does build lldb. However it does not build lldb-server.
So you can't just "lldb some-binary" and expect it to work.
I've updated the instructions to reflect that most of the time
you'll want both lldb and lldb-server.
Though there is a use case for building just lldb. I'm assuming
Mac OS (where you have debugserver) and if you only wanted to do
remote debug.
Fixes#59575
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D140385
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, the inferior is a new process and none of these memory
regions are still allocated. Clear them out.
Differential Revision: https://reviews.llvm.org/D140253
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.
This patch clang-formats AppendPathComponents in PathMappingList.cpp.
Without this patch, clang-format would indent the body of the
following function by four spaces.
When lldb is reading a user process corefile, it starts by finding
dyld, then finding the dyld_all_image_infos structure in dyld by
symbol name, then getting the list of loaded binaries. If it fails
to find the structure by name, it can't load binaries. There is
an additional fallback that this patch adds, which is to look for
this object by the section name it is stored in, if the symbol name
lookup fails.
Differential Revision: https://reviews.llvm.org/D140066
rdar://103369931
The current implementation nicely takes into account when the python interpreter is symlinked (or transitively within a symlinked directory). Sadly, `os.path.islink` returns `false` on Windows if instead of Windows symlinks, junctions are used. This has caused me issues after I started using `scoop` as my package manager on Windows, which creates junctions instead of symlinks.
The fix proposed in this patch is to check whether `realpath` returns a different path to `exe`, and if it does, to simply try again with that path.
The code could also be simplified since `sys.executable` is guaranteed to be absolute, and `os.readlink`, which can return a relative path, is no longer used.
Tested on Windows 11 with Python 3.11 as interpreter and Ubuntu 18.04 with Python 3.6
Differential Revision: https://reviews.llvm.org/D141042
lldb::LanguageType is used as a parameter in
SBExpressionOptions::SetLanguage(), which actually makes this type API
too. Commit 6eaedbb52f added a
`: uint16_t` to it, which broke binary compatibility for the SBAPI. This
patch reverts to the original enum.
I tried moving the entire enum into include/API, but that created a
cyclic module dependency between API and Utility. To keep things
simple, this just reverts to the original code and adds a warning.
rdar://103415402
Differential Revision: https://reviews.llvm.org/D141087
As a last resort, with a Mach-O corefile, lldb will iterate through
all memory segments looking for a dyld binary (for a userland process
core dump) or an xnu kernel binary (kernel coredump). We often
have metadata via LC_NOTEs so this final search mechanism is not
needed. During the rewrite in https://reviews.llvm.org/D133680 I
did not handle the case of finding the xnu kernel by exhaustive
search correctly.
rdar://103813200
The arm64 register context on Darwin has the 29 general purpose
registers, then pc/sp/lr/fp with different field names depending
on compile-time flags. Instead of accessing beyond the end of
the uint64_t[29] array, and upsetting the sanitizers, access those
registers correctly with the correct name.
Fixes a test failure on the ASAN CI bot, currently being
skipped, in TestEarlyProcessLaunch.py.
Differential Revision: https://reviews.llvm.org/D140067
rdar://103359354
