| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373954 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Someone wrote SetEffectiveSetEffectiveGroupID instead of SetEffectiveUserID.
After this fix, the android process list can show user names, e.g.
```
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE ARGUMENTS
====== ====== ========== ========== ========== ========== ============================== ============================
529 1 root 0 root 0 /sbin/ueventd
```
Reviewers: labath,clayborg,aadsm,xiaobai
Subscribers:
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373953 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373931 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Split out the logic to parse structure-like types into a separate
function, in an attempt to reduce the complexity of ParseTypeFromDWARF.
Inspired by discussion in https://reviews.llvm.org/D68130.
Differential Revision: https://reviews.llvm.org/D68422
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373927 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(& group together all the protected members & typedefs)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373926 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
was requested
Since D68289, a couple of tests on linux started being extremely flaky.
All of them were doing name-based attaching and were failing because
they couldn't find an unambiguous process to attach to.
The patch above changed the process finding logic, so that failure to
find a process name does not constitute an error. This meant that a lot
more transient processes showed up in the process list during the test
suite run. Previously, these processes would not appear as they would be
gone by the time we went to read their executable name, arguments, etc.
Now, this alone should not cause an issue were it not for the fact that
we were considering a process with no name as if it matched by default
(even if we were explicitly searching for a process with a specified
name). This meant that any of the "transient" processes with no name
would make the name match ambiguous. That clearly seems like a bug to me
so I fix that.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373925 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
If the .symtab section is stripped from the binary it might be that
there's a .gnu_debugdata section which contains a smaller .symtab in
order to provide enough information to create a backtrace with function
names or to set and hit a breakpoint on a function name.
This change looks for a .gnu_debugdata section in the ELF object file.
The .gnu_debugdata section contains a xz-compressed ELF file with a
.symtab section inside. Symbols from that compressed .symtab section
are merged with the main object file's .dynsym symbols (if any).
In addition we always load the .dynsym even if there's a .symtab
section.
For example, the Fedora and RHEL operating systems strip their binaries
but keep a .gnu_debugdata section. While gdb already can read this
section, LLDB until this patch couldn't. To test this patch on a
Fedora or RHEL operating system, try to set a breakpoint on the "help"
symbol in the "zip" binary. Before this patch, only GDB can set this
breakpoint; now LLDB also can do so without installing extra debug
symbols:
lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h
The above line runs LLDB in batch mode and on the "/usr/bin/zip -h"
target:
(lldb) target create "/usr/bin/zip"
Current executable set to '/usr/bin/zip' (x86_64).
(lldb) settings set -- target.run-args "-h"
Before the program starts, we set a breakpoint on the "help" symbol:
(lldb) b help
Breakpoint 1: where = zip`help, address = 0x00000000004093b0
Once the program is run and has hit the breakpoint we ask for a
backtrace:
(lldb) r
Process 10073 stopped
* thread #1, name = 'zip', stop reason = breakpoint 1.1
frame #0: 0x00000000004093b0 zip`help
zip`help:
-> 0x4093b0 <+0>: pushq %r12
0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056
0x4093b9 <+9>: movl $0x1, %edi
0x4093be <+14>: xorl %eax, %eax
Process 10073 launched: '/usr/bin/zip' (x86_64)
(lldb) bt
* thread #1, name = 'zip', stop reason = breakpoint 1.1
* frame #0: 0x00000000004093b0 zip`help
frame #1: 0x0000000000403970 zip`main + 3248
frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243
frame #3: 0x0000000000408cee zip`_start + 46
In order to support the .gnu_debugdata section, one has to have LZMA
development headers installed. The CMake section, that controls this
part looks for the LZMA headers and enables .gnu_debugdata support by
default if they are found; otherwise or if explicitly requested, the
minidebuginfo support is disabled.
GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6
(2013).
Reviewers: espindola, labath, jankratochvil, alexshap
Reviewed By: labath
Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D66791
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373810 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373803 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks for catching this, Pavel!
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This file really suffered from the Great Reformat. I'm adding a few
early returns to give the deeply nested code some more breathing room.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373778 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373777 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The recent change to expand arguments with the user's shell sometimes
caused a timeout and the error was not propagated.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I was writing an SB API client and it was crashing on:
bool DoExecute(SBDebugger dbg, char **command, SBCommandReturnObject &result) {
result = subcommand(dbg, "help");
That is because SBCommandReturnObject &result gets initialized inside LLDB by:
bool DoExecute(Args &command, CommandReturnObject &result) override {
// std::unique_ptr gets initialized here from `&result`!!!
SBCommandReturnObject sb_return(&result);
DoExecute(...);
sb_return.Release();
Differential revision: https://reviews.llvm.org/D67589
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373775 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Disabling this assert prevents lldb-server from crashing, which prevents it from finding the user and group names of a given process list.
Before this change, the process list didn't contain names:
```
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE ARGUMENTS
====== ====== ========== ========== ========== ========== ============================== ============================
27585 982 10098 10098 10098 10098 com.LogiaGroup.LogiaDeck
27623 982 10098 10098 10098 10098 com.digitalturbine.ignite.suspend.DataUsageRecorderService
28024 982 10199 10199 10199 10199 com.google.vr.vrcore
28061 983 10353 10353 10353 10353 com.instagram.android:videoplayer
28121 982 10045 10045 10045 10045 com.sec.spp.push
28325 982 10247 10247 10247 10247 com.facebook.orca
28714 982 10367 10367 10367 10367 com.samsung.android.dialer
29867 3208 2000 2000 2000 2000 aarch64-unknown-linux-android /system/bin/sh-c /data/local/tmp/lldb-server platform --listen *:5557 --server --log-file /data/local/tmp/logs --log-channels gdb-remote all --log-channels lldb all
```
After this change, the list looks much better
```
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE ARGUMENTS
====== ====== ========== ========== ========== ========== ============================== ============================
24459 1 wifi 1010 wifi 1010 aarch64-unknown-linux-android /vendor/bin/hw/wpa_supplicant-O/data/vendor/wifi/wpa/sockets -puse_p2p_group_interface=1 -g@android:wpa_wlan0
25098 982 u0_a42 10042 u0_a42 10042 com.samsung.android.messaging
25442 982 u0_a65 10065 u0_a65 10065 com.samsung.android.mobileservice
25974 982 u0_a9 10009 u0_a9 10009 com.samsung.android.contacts
26377 982 radio 1001 radio 1001 com.samsung.android.incallui
26390 983 u0_a26 10026 u0_a26 10026 com.samsung.android.game.gametools
26876 983 u0_a306 10306 u0_a306 10306 com.tencent.mm:push
```
Reviewers: clayborg,aadsm,xiaobai,labath
Subscribers:
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373760 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
By default `platform process list` only shows the processes of the current user that lldb-server can parse.
There are several problems:
- apk programs don't have an executable file. They instead use a package name as identifier.
- each apk also runs under a different user. That's how android works
- because of the user permission, some files like /proc/<pid>/{environ,exe} can't be read.
This results in a very small process list.
This is a local run on my machine
```
(lldb) platform process list
2 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
23291 3177 aarch64-unknown-linux-android sh
23301 23291 aarch64-unknown-linux-android lldb-server
```
However, I have 700 processes running at this time.
By implementing a few fallbacks for android, I've expanded this list to 202, filtering out kernel processes, which would presumably appear in this list if the device was rooted.
```
(lldb) platform process list
202 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
...
12647 3208 aarch64-unknown-linux-android sh
12649 12647 aarch64-unknown-linux-android lldb-server
12653 982 com.samsung.faceservice
13185 982 com.samsung.vvm
15899 982 com.samsung.android.spay
16220 982 com.sec.spp.push
17126 982 com.sec.spp.push:RemoteDlcProcess
19772 983 com.android.chrome
20209 982 com.samsung.cmh:CMH
20380 982 com.google.android.inputmethod.latin
20879 982 com.samsung.android.oneconnect:Receiver
21212 983 com.tencent.mm
24459 1 aarch64-unknown-linux-android wpa_supplicant
25974 982 com.samsung.android.contacts
26293 982 com.samsung.android.messaging
28714 982 com.samsung.android.dialer
31605 982 com.samsung.android.MtpApplication
32256 982 com.bezobidny
```
Something to notice is that the architecture is unkonwn for all apks. And that's fine, because run-as would be required to gather this information and that would make this entire functionality massively slow.
There are still several improvements to make here, like displaying actual user names, which I'll try to do in a following diff.
Note: Regarding overall apk debugging support from lldb. I'm planning on having lldb spawn lldb-server by itself with the correct user, so that everything works well. The initial lldb-server used for connecting to the remote platform can be reused for such purpose. Furthermore, eventually lldb could also launch that initial lldb-server on its own.
Reviewers: clayborg, aadsm, labath, xiaobai
Subscribers: srhines, krytarowski, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68289
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Link against clang-cpp dylib rather than split libs when
CLANG_LINK_CLANG_DYLIB is enabled.
Differential Revision: https://reviews.llvm.org/D68456
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
We should get the TargetAPI lock here to prevent the process of being destroyed while we are in the function. Thanks Jim for explaining what's going on.
Fixes rdar://54424754
Reviewers: jingham
Reviewed By: jingham
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67831
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373725 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
persistent AST
Summary:
As we figured out in D67803, importing declarations from a temporary ASTContext that were originally from a persistent ASTContext
causes a bunch of duplicated declarations where we end up having declarations in the target AST that have no associated ASTImporter that
can complete them.
I haven't figured out how/if we can solve this in the current way we do things in LLDB, but in the modern-type-lookup this is solvable
as we have a saner architecture with the ExternalASTMerger. As we can (hopefully) make modern-type-lookup the default mode in the future,
I would say we try fixing this issue here. As we don't use the hack that was reinstated in D67803 during modern-type-lookup, the test case for this
is essentially just printing any kind of container in `std::` as we would otherwise run into the issue that required a hack like D67803.
What this patch is doing in essence is that instead of importing a declaration from a temporary ASTContext, we instead check if the
declaration originally came from a persistent ASTContext (e.g. the debug information) and we directly import from there. The ExternalASTMerger
is already connected with ASTImporters to these different sources, so this patch is essentially just two parts:
1. Mark our temporary ASTContext/ImporterSource as temporary when we import from the expression AST.
2. If the ExternalASTMerger sees we import from the expression AST, instead of trying to import these temporary declarations, check if we
can instead import from the persistent ASTContext that is already connected. This ensures that all records from the persistent source actually
come from the persistent source and are minimally imported in a way that allows them to be completed later on in the target AST.
The next step is to run the ASTImporter for these temporary expressions with the MinimalImport mode disabled, but that's a follow up patch.
This patch fixes most test failures with modern-type-lookup enabled by default (down to 73 failing tests, which includes the 22 import-std-module tests
which need special treatment).
Reviewers: shafik, martong
Reviewed By: martong
Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68326
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate.
This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373687 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warning: unused variable 'py_func_obj' [-Wunused-variable]
PyObject *py_func_obj = m_py_obj;
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373685 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.
I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.
I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long 0xf0004668 ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov r0, sp
app_process32[0x1642]: andeq r0, r0, r0
```
Reviewers: clayborg, labath, wallace, espindola
Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68069
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373680 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PyClass_Check and everything it relied on seems gone from Python3.7. So
I won't check whether it is a class first...
Also cleaned up a couple of warnings.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I think that's what is confusing the modules build on the bots.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will allow us to write reusable scripted ThreadPlans, since
you can use key/value pairs with known keys in the plan to parametrize
its behavior.
Differential Revision: https://reviews.llvm.org/D68366
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373675 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Use this in the scripted breakpoint command. Added some tests for parsing
the key/value options. This uncovered a bug in handling parsing errors mid-line.
I also fixed that bug.
Differential Revision: https://reviews.llvm.org/D68363
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373673 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Now that `process list` works better on the android platform, the arch aarch64-unknown-linux-android appears quite often.
The existing printed width of the TRIPLE column is not long enough, which doesn't look okay.
E.g.
```
1561 1016 aarch64-unknown-linux-android ip6tables-restore
1999 1 aarch64-unknown-linux-android tlc_server
2332 982 com.android.systemui
2378 983 webview_zygote
```
Now, after adding 6 spaces, it looks better
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ============================== ============================
...
1561 1016 aarch64-unknown-linux-android ip6tables-restore
1999 1 aarch64-unknown-linux-android tlc_server
2332 982 com.android.systemui
2378 983 webview_zygote
2448 982 com.sec.location.nsflp2
```
Reviewers: clayborg, labath, xiaobai, aadsm
Reviewed By: labath
Subscribers: srhines, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68291
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373670 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
There's no need to wrap the just-constructed json::Array in a
json::Value, we can just return that and pass ownership to the
raw_ostream.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLDB handles shell expansion by running lldb-argdumper under a shell.
Currently, this is always /bin/sh on POSIX. This potentially leads to
different behavior between lldb and the user's current shell. Here's an
example of different expansions between shells:
$ /bin/bash -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
-config={Options:[key:foo_key]} -config={Options:[value:foo_value]}
$ /bin/zsh -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
zsh:1: no matches found: -config={Options:[key:foo_key]}
$ /bin/sh -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
-config={Options:[key:foo_key]} -config={Options:[value:foo_value]}
$ /bin/fish -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
-config=Options:[key:foo_key] -config=Options:[value:foo_value]
To reduce surprises, this patch returns the user's current shell. It
first looks at the SHELL environment variable. If that isn't set, it'll
ask for the user's default shell. Only if that fails, we'll fallback to
/bin/sh, which should always be available.
Differential revision: https://reviews.llvm.org/D68316
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Although it's called "GetString", StreamString::GetString actually
returns a StringRef. Creating a json object with a StringRef does not
make a copy, which means the StringRef will be dangling as soon as the
underlying stream is destroyed. Add a .str() to force the json object to
hold a copy of the string.
This fixes nearly every test on linux.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373572 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373564 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Add new methods to SBDebugger to set IO files as SBFiles instead of
as FILE* streams.
In future commits, the FILE* methods will be deprecated and these
will become the primary way to set the debugger I/O streams.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68181
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373563 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
SBFile is a scripting API wrapper for lldb_private::File
This is the first step in a project to enable arbitrary python
io.IOBase file objects -- including those that override the read()
and write() methods -- to be used as the main debugger IOStreams.
Currently this is impossible because python file objects must first
be converted into FILE* streams by SWIG in order to be passed into
the debugger.
full prototype: https://github.com/smoofra/llvm-project/tree/files
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67793
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373562 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While around, clean up support for a 8 years old OS.
<rdar://problem/55916729>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373510 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This code is only used under __arm64__, use the correct guard.
<rdar://problem/55916729>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373509 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Another block that's only compiled on __arm64__ and wasn't
updated.
<rdar://problem/55916729>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373508 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This didn't show up because nobody built __arm64__ in a while.
<rdar://problem/55916729>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch is the final step in my quest to get rid of the JSON parser
in LLDB. Vedant's coverage report [1] shows that it was mostly untested.
Furthermore, the LLVM implementation has a much nicer API and using it
means one less thing to maintain for LLDB.
[1] http://lab.llvm.org:8080/coverage/coverage-reports/index.html
Differential revision: https://reviews.llvm.org/D68305
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
GDBRemoteCommunicationServerCommon
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerCommon.
Differential revision: https://reviews.llvm.org/D68304
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
GDBRemoteCommunicationServerPlatform
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerPlatform.
Differential revision: https://reviews.llvm.org/D68302
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373499 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationClient.
Differential revision: https://reviews.llvm.org/D68301
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373498 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerLLGS.
Differential revision: https://reviews.llvm.org/D68299
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This makes sure that we associate DIEs that are imported from other CUs with the appropriate decl context.
Without this fix, nested classes can be dumped directly into their CU context if their parent was imported from another CU.
Reviewed By: teemperor, labath
Differential Revision: https://reviews.llvm.org/D68278
Patch by Jaroslav Sevcik!
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We now only use this function directly after initialization. As Clear()
resets the ASTContext back to its initial state, this is just a no-op.
There are no other users for this and we no longer can set the ASTContext
after construction, so Clear has no useful purpose anymore. It's also
mostly copy-pasted from Finalize().
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373460 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reason for this patch is the Ssame reason as for the previous patches:
Having a ClangASTContext and being able to switch the associated ASTContext isn't
a use case we have (or should have), so let's simplify all this code.
This way it becomes clearer in what order we initialize data structures.
The DWARFASTParserClangTests changes are necessary as the test is using
a ClangASTContext but relied on the fact that no called function ever calls
getASTContext() on our ClangASTContext (as that would create the ASTContext).
As we now always create the ASTContext the fact that we had an uninitialized
FileSystem made the test crash.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch replaces the hand-rolled JSON decoding in StructuredData with
LLVM's JSON library.
Differential revision: https://reviews.llvm.org/D68282
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373360 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch replaces the hand-rolled JSON emission in StructuredData with
LLVM's JSON library.
Differential revision: https://reviews.llvm.org/D68248
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@373359 91177308-0d34-0410-b5e6-96231b3b80d8
|
