summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
* Unify the two CRC implementationsHans Wennborg2019-10-091-5/+3
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* [lldb] Don't crash when the ASTImporter produces diagnostics but instead log ↵Raphael Isemann2019-10-091-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | them. When playing with the C++ module prototype I noticed I can get LLDB to crash by making a result type that depends on __make_integer_seq (a BuiltinTemplate) which is not supported by the ASTImporter yet. This causes the ASTImporter to emit a diagnostic when copying the type to the ScratchASTContext. As deporting the result type is done after we are done parsing and the Clang's diagnostic engine asserts that it can only be used during parsing, it crashes LLDB while trying to render the diagnostic in the HandleDiagnostic method of ClangDiagnosticManagerAdapter. This patch just moves the HandleDiagnostic call to Clang behind our check that we still have a DiagnosticManager (which we remove after parsing) which prevents the assert from firing. We also shouldn't ignore such diagnostics, so I added a log statement for them. There doesn't seem to way to test this as these diagnostic only happen when we copy a node that's not supported by the ASTImporter which should never happen once we can copy everything with the ASTImporter, so every test case we add here will eventually become invalid. (Note that most of this diff is just whitespace changes as we now use an early exit instead of a huge 'if' block). llvm-svn: 374145
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-081-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. 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 Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* Revert Trust the arange accelerator tables in dSYMsAdrian Prantl2019-10-081-13/+7
| | | | | | | This reverts r374117 (git commit 6399db2f6fd64fa250093368be40eb5ae3af513b) while inspecting bot breakage. llvm-svn: 374121
* Trust the arange accelerator tables in dSYMsAdrian Prantl2019-10-081-7/+13
| | | | | | | | | | | | | | | | When ingesting aranges from a dSYM it makes sense to 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 llvm-svn: 374117
* StopInfo/Mach: Delete PPC supportVedant Kumar2019-10-081-103/+0
| | | | | | | | | LLDB appears to have at least partial support for PPC, but PPC on Mach isn't a thing AFAIK. Differential Revision: https://reviews.llvm.org/D68661 llvm-svn: 374114
* Add test coverage to printing of enums and fix display of unsigned valuesFrederic Riss2019-10-081-6/+9
| | | | | | | | | | | | | | | TestCPP11EnumTypes.py should have covered all our bases when it comes to typed enums, but it missed the regression introduced in r374066. The reason it didn't catch it is somewhat funny: the test was copied over from another test that recompiled a source file with a different base type every time, but neither the test source nor the python code was adapted for testing enums. As a result, this test was just running 8 times the exact same checks on the exact same binary. This commit fixes the coverage and addresses the issue revealed by the new tests. llvm-svn: 374108
* StopInfo/Mach: Use early-exits, reflow messy comments, NFCIVedant Kumar2019-10-081-494/+481
| | | | llvm-svn: 374106
* [Reproducer] Don't isntrument methods that get called from the signal handler.Jonas Devlieghere2019-10-081-5/+4
| | | | | | | | | | | | | | LLDB's signal handlers call SBDebugger methods, which themselves try to be really careful about not doing anything non-signal safe. The Reproducer record macro is not careful though, and does unsafe things which potentially caused LLDB to crash. Given that these methods are not particularly interesting I've swapped the RECORD macros with DUMMY ones, so that we still register the API boundary but don't do anything non-signal safe. Thanks Jim for figuring this one out! llvm-svn: 374104
* Fix sign extension handling in DumpEnumValueFrederic Riss2019-10-081-0/+1
| | | | | | | | | | | | When an enumerator has an unsigned type and its high bit set, the code introduced in r374067 would fail to match it due to a sign extension snafu. This commit fixes this aspec of the code and should fix the bots. I think it's not a complete fix though, I'll add more test coverage and additional tweaks in a follow-up commit. llvm-svn: 374095
* exception handling in PythonDataObjects.Lawrence D'Anna2019-10-082-36/+392
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Python APIs nearly all can return an exception. They do this by returning NULL, or -1, or some such value and setting the exception state with PyErr_Set*(). Exceptions must be handled before further python API functions are called. Failure to do so will result in asserts on debug builds of python. It will also sometimes, but not usually result in crashes of release builds. Nearly everything in PythonDataObjects.h needs to be updated to account for this. This patch doesn't fix everything, but it does introduce some new methods using Expected<> return types that are safe to use. split off from https://reviews.llvm.org/D68188 Reviewers: JDevlieghere, jasonmolenda, labath, zturner Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68547 llvm-svn: 374094
* ObjectFileMachO: Replace std::map with llvm::DenseMap (NFC)Adrian Prantl2019-10-081-18/+10
| | | | | | | | This makes parsing the symbol table of clang marginally faster. (Hashtable versus tree). Differential Revision: https://reviews.llvm.org/D68605 llvm-svn: 374084
* Replace regex match with rfind (NFCish)Adrian Prantl2019-10-081-16/+15
| | | | | | | | | | This change is mostly performance-neutral since our regex engine is fast, but it's IMHO slightly more readable. Also, matching matching parenthesis is not a great match for regular expressions. Differential Revision: https://reviews.llvm.org/D68609 llvm-svn: 374082
* Replace static const StringRef with StringRef (NFC)Adrian Prantl2019-10-083-16/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D68597 llvm-svn: 374081
* Remove constructor and unused method (NFC).Adrian Prantl2019-10-081-15/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68595 llvm-svn: 374080
* Revert "[platform process list] add a flag for showing the processes of all ↵Shafik Yaghmour2019-10-083-8/+2
| | | | | | | | | | | users" This reverts commit 080f35fb875f52c924ee37ed4d56a51fe7056afa. Conflicts: packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py llvm-svn: 374077
* [lldb] Avoid resource leakKonrad Kleine2019-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before the pointer variable `args_dict` was assigned the result of an allocation with `new` and then `args_dict` is passed to `GetValueForKeyAsDictionary` which immediatly and unconditionally assigns `args_dict` to `nullptr`: ``` bool GetValueForKeyAsDictionary(llvm::StringRef key, Dictionary *&result) const { result = nullptr; ``` This caused a memory leak which was found in my coverity scan instance under CID 224753: https://scan.coverity.com/projects/kwk-llvm-project. Reviewers: jankratochvil, teemperor Reviewed By: teemperor Subscribers: teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68638 llvm-svn: 374071
* Simplify LZMA decoding by using ArrayRef::take_backKonrad Kleine2019-10-081-6/+6
| | | | | | | | | | | | | | Summary: Follow-up for D66791#inline-616303 Reviewers: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68647 llvm-svn: 374069
* Add pretty printing of Clang "bitfield" enumsFrederic Riss2019-10-081-8/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Using enumerators as flags is standard practice. This patch adds support to LLDB to display such enum values symbolically, eg: (E) e1 = A | B If enumerators don't cover the whole value, the remaining bits are displayed as hexadecimal: (E) e4 = A | 0x10 Detecting whether an enum is used as a bitfield or not is complicated. This patch implements a heuristic that assumes that such enumerators will either have only 1 bit set or will be a combination of previous values. This patch doesn't change the way we currently display enums which the above heuristic would not consider as bitfields. Reviewers: jingham, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67520 llvm-svn: 374067
* Extract and simplify DumpEnumValueFrederic Riss2019-10-081-39/+29
| | | | llvm-svn: 374066
* Revert "[lldb-server/android] Show more processes and package name when ↵Pavel Labath2019-10-081-45/+34
| | | | | | | | | necessary" This reverts r373758 because it causes several to test to be flaky (= failing ~90% of the time) on linux. llvm-svn: 374030
* Revert "ProcessInstanceInfoMatch: Don't match processes with no name if a ↵Jonas Devlieghere2019-10-081-1/+1
| | | | | | | | name match was requested" This breaks TestProcessAttach and TestHelloWorld on Darwin. llvm-svn: 374008
* [lldb] Reverts part of 61f471aHaibo Huang2019-10-081-1/+6
| | | | | | | | | | | Seems I wrongly merged an old patch. Reverts the change related to python dir for windows. FileSpec should always contain normalized path. I.e. using '/' even in windows. llvm-svn: 373998
* [MachO] Fix symbol merging during symtab parsing.Jonas Devlieghere2019-10-081-23/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The symtab parser in ObjectFileMachO has logic to coalesce debug (STAB) and non-debug symbols, based on the address and the symbol name for static (STSYM) and global symbols (GSYM) respectively. It makes the assumption that the debug variant is always encountered first. Rather than creating a second entry in the symbol table for the non-debug symbol, the latter gets merged into the existing debug symbol. This breaks when the linker emits the non-debug symbol first. We'd end up with two entries in the symbol table, each containing part of the information LLDB relies on. Indeed, commenting out the merging logic breaks the test suite spectacularly. This patch solves that problem by always parsing the debug symbols first. This guarantees that the assumption for merging holds. I'm not particularly happy with adding a lambda, but after numerous attempts this is the best solution I could come up with. The symtab parsing logic is pretty complex in that it touches a lot of things. I've experienced first hand that it's very easy to break things. I believe this approach strikes a balance between fixing the issue while limiting the risk of regressions. Differential revision: https://reviews.llvm.org/D68536 llvm-svn: 373994
* [lldb] Unifying lldb python pathHaibo Huang2019-10-073-40/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on mgorny@'s D67890 There are 3 places where python site-package path is calculated independently: 1. finishSwigPythonLLDB.py where files are written to site-packages. 2. lldb/scripts/CMakeLists.txt where site-packages are installed. 3. ScriptInterpreterPython.cpp where site-packages are added to PYTHONPATH. This change creates the path once and use it everywhere. So that they will not go out of sync. Also it provides a chance for cross compiling users to specify the right path for site-packages. Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68442 llvm-svn: 373991
* [Symbol] Remove unused method ClangASTContext::GetObjCClassNameAlex Langford2019-10-071-19/+0
| | | | llvm-svn: 373990
* Mark constructor as default and remove implementation (NFC)Adrian Prantl2019-10-071-2/+0
| | | | llvm-svn: 373968
* [MachO] Shuffle some things around in ParseSymtab (NFC)Jonas Devlieghere2019-10-071-5/+4
| | | | llvm-svn: 373954
* [gdb-remote] process properly effective uidWalter Erquinigo2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | 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: llvm-svn: 373953
* [platform process list] add a flag for showing the processes of all usersWalter Erquinigo2019-10-073-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: llvm-svn: 373931
* [DWARFASTParserClang] Factor out structure-like type parsing, NFCVedant Kumar2019-10-074-432/+473
| | | | | | | | | | | 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 llvm-svn: 373927
* [DWARFASTParserClang] Delete commented-out typedef, NFCVedant Kumar2019-10-071-18/+19
| | | | | | (& group together all the protected members & typedefs) llvm-svn: 373926
* ProcessInstanceInfoMatch: Don't match processes with no name if a name match ↵Pavel Labath2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 373925
* [lldb][ELF] Read symbols from .gnu_debugdata sect.Konrad Kleine2019-10-074-8/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373891
* [MachO] Reduce indentation further in ParseSymtab (NFC)Jonas Devlieghere2019-10-041-176/+177
| | | | llvm-svn: 373810
* [MachO] Move nlist parsing into helper function (NFC)Jonas Devlieghere2019-10-041-21/+14
| | | | llvm-svn: 373803
* [Host] Return status directly from RunShellCommandJonas Devlieghere2019-10-042-8/+4
| | | | | | Thanks for catching this, Pavel! llvm-svn: 373783
* [MachO] Add early returns to save some indentation.Jonas Devlieghere2019-10-041-2828/+2776
| | | | | | | 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. llvm-svn: 373778
* [MachO] Reformat before making changes to this file (NFC)Jonas Devlieghere2019-10-041-200/+206
| | | | llvm-svn: 373777
* [Host] Don't discard return value from RunShellCommandJonas Devlieghere2019-10-042-5/+16
| | | | | | | The recent change to expand arguments with the user's shell sometimes caused a timeout and the error was not propagated. llvm-svn: 373776
* [lldb] Fix crash on SBCommandReturnObject & assignmentJan Kratochvil2019-10-042-56/+68
| | | | | | | | | | | | | | | | | 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 llvm-svn: 373775
* [process info] Remove assert in DoGetGroupNameWalter Erquinigo2019-10-041-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: llvm-svn: 373760
* [lldb-server/android] Show more processes and package name when necessaryWalter Erquinigo2019-10-041-34/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373758
* [lldb] [cmake] Support linking against clang-cpp dylibMichal Gorny2019-10-0410-24/+36
| | | | | | | | | Link against clang-cpp dylib rather than split libs when CLANG_LINK_CLANG_DYLIB is enabled. Differential Revision: https://reviews.llvm.org/D68456 llvm-svn: 373734
* [lldb] Get the TargetAPI lock in SBProcess::IsInstrumentationRuntimePresentRaphael Isemann2019-10-041-0/+3
| | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373725
* [lldb] Fix -Wreorder-ctor in r373673Sam McCall2019-10-041-13/+12
| | | | llvm-svn: 373721
* [lldb][modern-type-lookup] No longer import temporary declarations into the ↵Raphael Isemann2019-10-041-98/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373711
* Revert "Explicitly set entry point arch when it's thumb"Antonio Afonso2019-10-041-40/+0
| | | | | | | | Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate. This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be. llvm-svn: 373687
* [Python] Remove unused variableJonas Devlieghere2019-10-041-1/+0
| | | | | | warning: unused variable 'py_func_obj' [-Wunused-variable] PyObject *py_func_obj = m_py_obj; llvm-svn: 373686
* Properly handle instantiation-dependent array bounds.Richard Smith2019-10-041-2/+2
| | | | | | | | | 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. llvm-svn: 373685
OpenPOWER on IntegriCloud