summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* [test] Rename `Modules` to `ObjectFile` (NFC)Jonas Devlieghere2019-10-0762-0/+0
| | | | llvm-svn: 373955
* [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-072-3/+7
| | | | | | | | | | | | | | | | | | 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-075-4/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-1/+18
| | | | | | | | | | | | | | | | | | | | | | | 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-0715-8/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Do not install lit-cpuidSylvestre Ledru2019-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: AFAIK, lit-cpuid is used by the tests. Installing it causes LLVMExports*.cmake files to depend on this program. It causes some serious packaging issues as it would means that llvm-dev depends on lldb. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941082 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941306 See also https://bugs.llvm.org/show_bug.cgi?id=43035 for a similar issue caused by https://reviews.llvm.org/D56606 Reviewers: mgorny Reviewed By: mgorny Subscribers: delcypher, lldb-commits Differential Revision: https://reviews.llvm.org/D68537 llvm-svn: 373819
* [MachO] Reduce indentation further in ParseSymtab (NFC)Jonas Devlieghere2019-10-041-176/+177
| | | | llvm-svn: 373810
* [test] Run TestLaunchWithShellExpand with /bin/sh on POSIX.Jonas Devlieghere2019-10-041-0/+4
| | | | | | | Now that we do shell expansion on POSIX with the user's shel, this test can potentially fail. This should ensure that we always use /bin/sh. llvm-svn: 373804
* [MachO] Move nlist parsing into helper function (NFC)Jonas Devlieghere2019-10-041-21/+14
| | | | llvm-svn: 373803
* [debugserver] Don't link against Cocoa, it's not needed.Davide Italiano2019-10-041-2/+0
| | | | | | <rdar://problem/55916729> llvm-svn: 373795
* Expand on the qfProcessInfo documentation, add examples fromJason Molenda2019-10-041-4/+33
| | | | | | lldb-gdb-remote.txt and text explaining the no-criteria mode. llvm-svn: 373789
* [lldb] [testsuite] Mark TestSBCommandReturnObject as failing on WindowsJan Kratochvil2019-10-041-0/+3
| | | | | | | | | | | | | | | | | | | Filed: testsuite: TestSBCommandReturnObject: object has no attribute 'dylibPath' https://bugs.llvm.org/show_bug.cgi?id=43570 http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9530/steps/test/logs/stdio AttributeError: 'TestSBCommandReturnObject' object has no attribute 'dylibPath' Fix crash on SBCommandReturnObject & assignment https://reviews.llvm.org/D67589 env = {self.dylibPath: self.getLLDBLibraryEnvVal()} I do not know how to link with liblldb on Windows so marking it as failing on Windows. llvm-svn: 373787
* [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-047-92/+152
| | | | | | | | | | | | | | | | | 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
* Componentize lldb/scripts to use with LLVM_DISTRIBUTION_COMPONENTSAntonio Afonso2019-10-041-1/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: I'd like to install lldb using the install-distribution target with LLVM_DISTRIBUTION_COMPONENTS but this is currently not possible as the lldb/scripts do not provide any component we can use and install the python scripts. For this effect I created an lldb-python-scripts target and added the install-lldb-python-scripts llvm install target. I tested with: cmake ... -DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLVM_DISTRIBUTION_COMPONENTS="lldb;liblldb;lldb-python-scripts" ... DESTDIR=... ninja install-distribution Then checked with bin/lldb -x -o 'script import lldb' Reviewers: labath, xiaobai, clayborg, lanza Subscribers: mgorny, lldb-commits, smeenai, wallace Tags: #lldb Differential Revision: https://reviews.llvm.org/D68370 llvm-svn: 373768
* [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-0412-27/+50
| | | | | | | | | 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 that 'ninja clean' breaks the build by deleting debugserver_vers.cRaphael Isemann2019-10-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We mark debugserver_vers.c as a generated file in CMake. This means that when we run `ninja clean` we end up deleting that file, but any following `ninja` invocation will fail due to the file missing. The file can't be generated as `ninja` doesn't know it has to rerun CMake to create the file. Turns out that marking the output of configure_file as generated is wrong as explained in this bug report: https://gitlab.kitware.com/cmake/cmake/issues/18032 This patch just removes that property. The only side effect of this seems to be that this file maybe shows up in your IDE when opening our CMake project, but that seems like a small sacrifice. This patch can be quickly tested by running `ninja clean ; ninja lldbDebugserverCommon`. Before this patch the build will fail due to debugserver_vers.c missing. Reviewers: JDevlieghere, labath Reviewed By: labath Subscribers: mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68376 llvm-svn: 373723
* [lldb] Fix -Wreorder-ctor in r373673Sam McCall2019-10-041-13/+12
| | | | llvm-svn: 373721
* [lldb] Fix typo in r373675Sam McCall2019-10-041-1/+1
| | | | llvm-svn: 373719
* [lldb][modern-type-lookup] No longer import temporary declarations into the ↵Raphael Isemann2019-10-043-98/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-043-179/+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
* Explicitly set entry point arch when it's thumbAntonio Afonso2019-10-043-0/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373680
* Python3 doesn't seem to allow you to tell whether an object is a classJim Ingham2019-10-033-5/+2
| | | | | | | | | 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. llvm-svn: 373679
* Forgot to change the header guards on OptionGroupPythonClassWithDict.Jim Ingham2019-10-032-4/+5
| | | | | | I think that's what is confusing the modules build on the bots. llvm-svn: 373677
* Pass an SBStructuredData to scripted ThreadPlans on use.Jim Ingham2019-10-0322-137/+336
| | | | | | | | | | 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 llvm-svn: 373675
* Break out the Python class & key/value options into a separate OptionGroup.Jim Ingham2019-10-038-41/+224
| | | | | | | | | | 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 llvm-svn: 373673
* [process list] make the TRIPLE column widerWalter Erquinigo2019-10-032-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373670
* [lldb] Remove unused variables.Haibo Huang2019-10-031-5/+0
| | | | | | Fixes the comment in https://reviews.llvm.org/D67993 llvm-svn: 373669
* [lldb] Calculate relative path for symbol linksHaibo Huang2019-10-031-17/+4
| | | | | | | | | | | | | | Summary: This replaces the hard coded path. Reviewers: labath, mgorny Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67993 llvm-svn: 373668
* [test] Disable TestCustomShell on LinuxJonas Devlieghere2019-10-031-0/+4
| | | | | | | ShellExpandArguments is unimplemented on Linux. I need to come up with another way to test this on Linux. llvm-svn: 373662
* [JSON] Don't wrap json::Array in a value (NFC)Jonas Devlieghere2019-10-031-3/+3
| | | | | | | | 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. llvm-svn: 373656
* [Host] Return the user's shell from GetDefaultShellJonas Devlieghere2019-10-033-9/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373644
* "Fix" TestFileHandle.py on non-darwin platformsPavel Labath2019-10-031-0/+8
| | | | | | | | | | | | | | | | | | This test exposed a very long standing issue that the python file objects returned by the FILE* typemap were unusable on non-darwin platforms. The reason they work on darwin is that they rely on a non-standard extension to fetch the "mode" of a FILE* object. On other platforms, this code was #ifdefed out, and so we were returning an empty mode. As there's no portable way to get this information, I just change the non-darwin path to return "r+", which should permit both reading and writing operations on the object. If the underlying file descriptor turns out to be incompatible with this mode, the operating system should return EBADF (or equivalent), instead of the "file not open for XXX" error from python. llvm-svn: 373573
* Fix a use-after-free in GDBRemoteCommunicationServerLLGSPavel Labath2019-10-031-1/+2
| | | | | | | | | | | | 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. llvm-svn: 373572
* factor out an abstract base class for FileLawrence D'Anna2019-10-0317-262/+367
| | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373564
* SBDebugger::SetInputFile, SetOutputFile, etc.Lawrence D'Anna2019-10-039-35/+275
| | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373563
* new api class: SBFileLawrence D'Anna2019-10-0316-25/+428
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 373562
* [ARM64] XPC services are unsupported on device.Davide Italiano2019-10-021-2/+2
| | | | | | | | While around, clean up support for a 8 years old OS. <rdar://problem/55916729> llvm-svn: 373510
* [RegisterContextDarwin_arm64] Include the headers for getsysctlbyname.Davide Italiano2019-10-021-0/+5
| | | | | | | | This code is only used under __arm64__, use the correct guard. <rdar://problem/55916729> llvm-svn: 373509
OpenPOWER on IntegriCloud