| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Extend support in LLDB for WebAssembly. This PR adds a new Process
plugin (ProcessWasm) that extends ProcessGDBRemote for WebAssembly
targets. It adds support for WebAssembly's memory model with separate
address spaces, and the ability to fetch the call stack from the
WebAssembly runtime.
I have tested this change with the WebAssembly Micro Runtime (WAMR,
https://github.com/bytecodealliance/wasm-micro-runtime) which implements
a GDB debug stub and supports the qWasmCallStack packet.
```
(lldb) process connect --plugin wasm connect://localhost:4567
Process 1 stopped
* thread #1, name = 'nobody', stop reason = trace
frame #0: 0x40000000000001ad
wasm32_args.wasm`main:
-> 0x40000000000001ad <+3>: global.get 0
0x40000000000001b3 <+9>: i32.const 16
0x40000000000001b5 <+11>: i32.sub
0x40000000000001b6 <+12>: local.set 0
(lldb) b add
Breakpoint 1: where = wasm32_args.wasm`add + 28 at test.c:4:12, address = 0x400000000000019c
(lldb) c
Process 1 resuming
Process 1 stopped
* thread #1, name = 'nobody', stop reason = breakpoint 1.1
frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12
1 int
2 add(int a, int b)
3 {
-> 4 return a + b;
5 }
6
7 int
(lldb) bt
* thread #1, name = 'nobody', stop reason = breakpoint 1.1
* frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12
frame #1: 0x40000000000001e5 wasm32_args.wasm`main at test.c:12:12
frame #2: 0x40000000000001fe wasm32_args.wasm
```
This PR is based on an unmerged patch from Paolo Severini:
https://reviews.llvm.org/D78801. I intentionally stuck to the
foundations to keep this PR small. I have more PRs in the pipeline to
support the other features/packets.
My motivation for supporting Wasm is to support debugging Swift compiled
to WebAssembly:
https://www.swift.org/documentation/articles/wasm-getting-started.html
|
|
|
|
|
|
(#107163)
…ror() [NFC]
|
|
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.
This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()
Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form
` ResultTy DoFoo(Status& error)
`
to
` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?
The interesting changes are in Status.h and Status.cpp, all other
changes are mostly
` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.
|
|
Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable
modules in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).
This commit fixes that.
|
|
Currently, LLDB prints out a rather unhelpful error message when passed
a file that it doesn't recognize as an executable.
> error: '/path/to/file' doesn't contain any 'host' platform
> architectures: arm64, armv7, armv7f, armv7k, armv7s, armv7m, armv7em,
> armv6m, armv6, armv5, armv4, arm, thumbv7, thumbv7k, thumbv7s,
> thumbv7f, thumbv7m, thumbv7em, thumbv6m, thumbv6, thumbv5, thumbv4t,
> thumb, x86_64, x86_64, arm64, arm64e
I did a quick search internally and found at least 24 instances of users
being confused by this. This patch improves the error message when it
doesn't recognize the file as an executable, but keeps the existing
error message otherwise, i.e. when it's an object file we understand,
but the current platform doesn't support.
|
|
|
|
The Platform class currently has two functions to resolve an executable:
`ResolveExecutable` and `ResolveRemoteExecutable`. The former strictly
deals with local files while the latter can handle potentially remote
files. I couldn't figure out why the distinction matters, at the latter
is a super-set of the former.
To make things even more confusion, we had a similar but not identical
implementation in RemoteAwarePlatform where its implementation of
`ResolveExecutable` could handle remote files. To top it all off, we had
copy-pasted implementation, dead code included in
`PlatformAppleSimulator` and `PlatformRemoteDarwinDevice`.
I went ahead and unified all the different implementation on the
original `ResolveRemoteExecutable` implementation. As far as I can tell,
it should work for every other platform, and the test suite (on macOS)
seems to agree with me, except for a small wording change.
|
|
Windows host (#91887)
Target::Install() set 0700 permissions for the main executable file.
Platform::Install() just copies permissions from the source. But the
permission eFilePermissionsUserExecute is missing on the Windows host. A
lot of tests failed in case of Windows host and Linux target because of
this issue. There is no API to provide the exec flag. This patch set the
permission eFilePermissionsUserExecute for all files installed via
Platform::Install() from the Windows host. It fixes a lot of tests in
case of Windows host and Linux target.
|
|
This is a retake of https://github.com/llvm/llvm-project/pull/90921
which got reverted because I forgot to modify the CalculateMD5 unit test
I had added in https://github.com/llvm/llvm-project/pull/88812
The prior failing build is here:
https://lab.llvm.org/buildbot/#/builders/68/builds/73622
To make sure this error doesn't happen, I ran `ninja
ProcessGdbRemoteTests` and then executed the resulting test binary and
observed the `CalculateMD5` test passed.
# Overview
In my previous PR: https://github.com/llvm/llvm-project/pull/88812,
@JDevlieghere suggested to match return types of the various calculate
md5 functions.
This PR achieves that by changing the various calculate md5 functions to
return `llvm::ErrorOr<llvm::MD5::MD5Result>`.
The suggestion was to go for `std::optional<>` but I opted for
`llvm::ErrorOr<>` because local calculate md5 was already possibly
returning `ErrorOr`.
To make sure I didn't break the md5 calculation functionality, I ran
some tests for the gdb remote client, and things seem to work.
# Testing
1. Remote file doesn't exist
1. Remote file differs
1. Remote file matches
## Test gaps
Unfortunately, I had to modify
`lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I
can't test the changes there. Hopefully, the existing test suite / code
review from whomever is reading this will catch any issues.
|
|
Reverts llvm/llvm-project#90921
|
|
# Overview
In my previous PR: https://github.com/llvm/llvm-project/pull/88812,
@JDevlieghere suggested to match return types of the various calculate
md5 functions.
This PR achieves that by changing the various calculate md5 functions to
return `llvm::ErrorOr<llvm::MD5::MD5Result>`.
The suggestion was to go for `std::optional<>` but I opted for
`llvm::ErrorOr<>` because local calculate md5 was already possibly
returning `ErrorOr`.
To make sure I didn't break the md5 calculation functionality, I ran
some tests for the gdb remote client, and things seem to work.
# Testing
1. Remote file doesn't exist
1. Remote file differs
1. Remote file matches
## Test gaps
Unfortunately, I had to modify
`lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I
can't test the changes there. Hopefully, the existing test suite / code
review from whomever is reading this will catch any issues.
Co-authored-by: Anthony Ha <antha@microsoft.com>
|
|
This PR adds a check within `PutFile` to exit early when both local and
destination files have matching MD5 hashes. If they differ, or there is
trouble getting the hashes, the regular code path to put the file is
run.
As I needed this to talk to an `lldb-server` which runs the gdb-remote
protocol, I enabled `CalculateMD5` within `Platform/gdb-server` and also
found and fixed a parsing bug within it as well. Before this PR, the
client is incorrectly parsing the response packet containing the
checksum; after this PR, hopefully this is fixed. There is a test for
the parsing behavior included in this PR.
---------
Co-authored-by: Anthony Ha <antha@microsoft.com>
|
|
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
|
|
...and follow ups.
As it has caused test failures on Linux Arm and AArch64:
https://lab.llvm.org/buildbot/#/builders/96/builds/49126
https://lab.llvm.org/buildbot/#/builders/17/builds/45824
```
lldb-shell :: Subprocess/clone-follow-child-wp.test
lldb-shell :: Subprocess/fork-follow-child-wp.test
lldb-shell :: Subprocess/vfork-follow-child-wp.test
```
This reverts commit a6c62bf1a4717accc852463b664cd1012237d334,
commit a0a1ff3ab40e347589b4e27d8fd350c600526735 and commit
fc6b72523f3d73b921690a713e97a433c96066c6.
|
|
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
|
|
Add the ability to list all processes through the SB API.
rdar://116188959
|
|
ConstString can be implicitly converted into a llvm::StringRef. This is
very useful in many places, but it also hides places where we are
creating a ConstString only to use it as a StringRef for the entire
lifespan of the ConstString object.
I locally removed the implicit conversion and found some of the places we
were doing this.
Differential Revision: https://reviews.llvm.org/D159237
|
|
StreamFile subclasses Stream (from lldbUtility) and is backed by a File
(from lldbHost). It does not depend on anything from lldbCore or any of its
sibling libraries, so I think it makes sense for this to live in
lldbHost instead.
Differential Revision: https://reviews.llvm.org/D157460
|
|
This is an enhancement for the locate module callback.
https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580/6
On Android remote platform, module UUID is resolved by
Platform::GetRemoteSharedModule. Which means the current
Target::CallLocateModuleCallbackIfSet() call undesirably is not able to pass the
module UUID to the locate module callback.
This diff moves the CallLocateModuleCallbackIfSet() implementation from Target
to Platform to allows both Target and Platform can call it. One is from the
current Target call site, and second is from Platform after resolving the module
UUID.
As the result of this change, the locate module callback may be called twice
for a same module on remote platforms. And it should be ok.
- First, without UUID.
- The locate module callback is allowed to return an error
if the callback requires UUID.
- Second, with UUID, if the first callback call did not return a module.
Differential Revision: https://reviews.llvm.org/D156066
|
|
This reverts commit df054499c35cdda02b196b2ca5c0a326abdc0a29.
Reverting because of build errors
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
|
|
This reverts commit 7f1028e9df52b4e7246f189a24684b1ca8c9bfbe.
This is because test failures
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
|
|
RFC https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580
Updated Target::GetOrCreateModule to call locate module callback if set.
- include/lldb/Target/Platform.h, source/Target/Platform.cpp
- Implemented SetLocateModuleCallback and GetLocateModuleCallback*
- include/lldb/Target/Target.h, source/Target/Target.cpp
- Implemented CallLocateModuleCallbackIfSet.
- unittests/Target/LocateModuleCallbackTest.cpp
- Added comprehensive GetOrCreateModule tests.
Differential Revision: https://reviews.llvm.org/D153734
|
|
reference
These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we always feed it with a valid
pointer. It would therefore make more sense to have this take a
reference.
Differential Revision: https://reviews.llvm.org/D154883
|
|
Remove the unmatched closing paren )
|
|
https://github.com/llvm/llvm-project/issues/62750
I setup a simple test with a large .so (~100MiB) that was only present on the target machine
but not present on the local machine, and ran a lldb server on the target and connectd to it.
LLDB properly downloads the file from the remote, but it does so at a very slow speed, even over a hardwired 1Gbps connection!
Increasing the buffer size for downloading these helps quite a bit.
Test setup:
```
$ cat gen.py
print('const char* hugeglobal = ')
for _ in range(1000*500):
print(' "' + '1234'*50 + '"')
print(';')
print('const char* mystring() { return hugeglobal; }')
$ gen.py > huge.c
$ mkdir libdir
$ gcc -fPIC huge.c -Wl,-soname,libhuge.so -o libdir/libhuge.so -shared
$ cat test.c
#include <string.h>
#include <stdio.h>
extern const char* mystring();
int main() {
printf("%d\n", strlen(mystring()));
}
$ gcc test.c -L libdir -l huge -Wl,-rpath='$ORIGIN' -o test
$ rsync -a libdir remote:~/
$ ssh remote bash -c "cd ~/libdir && /llvm/buildr/bin/lldb-server platform --server --listen '*:1234'"
```
in another terminal
```
$ rm -rf ~/.lldb # clear cache
$ cat connect.lldb
platform select remote-linux
platform connect connect://10.0.0.14:1234
file test
b main
r
image list
c
q
$ time /llvm/buildr/bin/lldb --source connect.lldb
```
Times with various buffer sizes:
1kiB (current): ~22s
8kiB: ~8s
16kiB: ~4s
32kiB: ~3.5s
64kiB: ~2.8s
128kiB: ~2.6s
256kiB: ~2.1s
512kiB: ~2.1s
1MiB: ~2.1s
2MiB: ~2.1s
I choose 512kiB from this list as it seems to be the place where the returns start diminishing and still isn't that much memory
My understanding of how this makes such a difference is ReadFile issues a request for each call, and larger buffer means less round trip times. The "ideal" situation is ReadFile() being async and being able to issue multiple of these, but that is much more work for probably little gains.
NOTE: this is my first contribution, so wasn't sure who to choose as a reviewer. Greg Clayton seems to be the most appropriate of those in CODE_OWNERS.txt
Reviewed By: clayborg, jasonmolenda
Differential Revision: https://reviews.llvm.org/D153060
|
|
These don't need to be ConstStrings. They don't really benefit much from
deduplication and comparing them isn't on a hot path, so they don't
really benefit much from quick comparisons.
Differential Revision: https://reviews.llvm.org/D152331
|
|
This patch is a continuation of 6f8b33f6dfd0 and eliminates the
{Get,Set}PropertyAtIndexAsFileSpec functions.
|
|
Use templates to simplify {Get,Set}PropertyAtIndex. It has always
bothered me how cumbersome those calls are when adding new properties.
After this patch, SetPropertyAtIndex infers the type from its arguments
and GetPropertyAtIndex required a single template argument for the
return value. As an added benefit, this enables us to remove a bunch of
wrappers from UserSettingsController and OptionValueProperties.
Differential revision: https://reviews.llvm.org/D149774
|
|
As far as I can tell, this just computes the filename of the FileSpec,
which is already conveniently stored in m_filename. We can use
FileSpec::GetFilename() instead.
Differential Revision: https://reviews.llvm.org/D149663
|
|
The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional and
simplify all the callers.
|
|
Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.
|
|
Similar to fdbe7c7faa54, refactor OptionValueProperties to return a
std::optional instead of taking a fail value. This allows the caller to
handle situations where there's no value, instead of being unable to
distinguish between the absence of a value and the value happening the
match the fail value. When a fail value is required,
std::optional::value_or() provides the same functionality.
|
|
This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.
This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.
However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.
So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.
Differential Revision: https://reviews.llvm.org/D148863
|
|
Add MSP430 to the list of available targets, implement MSP430 ABI, add support for debugging targets with 16-bit address size.
The update is intended for use with MSPDebug, a GDB server implementation for MSP430.
Reviewed By: bulbazord, DavidSpickett
Differential Revision: https://reviews.llvm.org/D146965
|
|
This reverts commit 82c02b733c7736507a41a26bebd37d3f8e88bd4e.
Apparently, the original patch was not rebased onto `main
|
|
Add MSP430 to the list of available targets, implement MSP430 ABI, add support for debugging targets with 16-bit address size.
The update is intended for use with MSPDebug, a GDB server implementation for MSP430.
Reviewed By: bulbazord, DavidSpickett
Differential Revision: https://reviews.llvm.org/D146965
|
|
This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3.
As discussed in https://reviews.llvm.org/D146668 we'll find another way
forward.
|
|
The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is
so that we can create the appropriate UnixSignals object based on an
ArchSpec. Instead of using the ArchSpec, we can instead take advantage
of the Platform associated with the current Target.
This is accomplished by adding a new method to Platform,
CreateUnixSignals, which will create the correct UnixSignals object for
us. We then can use `Platform::GetUnixSignals` and rely on that to give
us the correct signals as needed.
Differential Revision: https://reviews.llvm.org/D146263
|
|
Platform::CreateInstance"
This reverts commit 2d53527e9c64c70c24e1abba74fa0a8c8b3392b1.
|
|
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 is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
|
|
This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
Use `break 0x5` for LoongArch software breakpoint traps.
The magic number 0x5 means `BRK_SSTEPBP` as defined in
the kernel header `asm/break.h` on LoongArch.
Reviewed By: SixWeining, xen0n
Differential Revision: https://reviews.llvm.org/D137519
|
|
Add:
- RV64C instructions sets.
- corresponding unittests.
- `c.break` code for lldb and lldb-server
Fix:
- wrong decoding of imm in `DecodeSType`
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D136362
|
|
Complete support of the binary-addresses key in the qProcessInfo packet
in ProcessGDBRemote, for detecting if one of the binaries needs to be
handled by a Platform plugin, and can be used to set the Process'
DynamicLoader plugin and the Target's Platform plugin.
Implement this method in PlatformDarwinKernel to recognize a kernel
fileset at that address, find the actual kernel address in the
fileset, set DynamicLoaderDarwinKernel and PlatformDarwinKernel
in the Process/Target; register the kernel address with the dynamic
loader so it will be loaded later during attach.
This patch only addresses the live debug scenario with a gdb remote
serial protocol connection. I'll handle corefiles in a subsequent
patch that builds on this.
Differential Revision: https://reviews.llvm.org/D133534
rdar://98754861
|
|
|
