summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-083-35/+66
| | | | | | | | | | | | | | | 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-082-498/+488
| | | | llvm-svn: 374106
* [Reproducer] Don't isntrument methods that get called from the signal handler.Jonas Devlieghere2019-10-082-5/+6
| | | | | | | | | | | | | | 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
* [CMake] Fix building without python on WindowsAlex Langford2019-10-081-2/+7
| | | | | | | | Summary: find_python_libs_windows might set LLDB_DISABLE_PYTHON to ON. Unfortunately we do not re-check this variable before using variables filled in by find_python_libs_windows, leading to a failed configuration. llvm-svn: 374100
* Reflow/fix doxygen comments.Adrian Prantl2019-10-081-10/+16
| | | | llvm-svn: 374096
* 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-082-18/+40
| | | | | | | | 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-082-17/+16
| | | | | | | | | | 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-085-72/+4
| | | | | | | | | | | users" This reverts commit 080f35fb875f52c924ee37ed4d56a51fe7056afa. Conflicts: packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py llvm-svn: 374077
* [Testsuite] Get rid of most of the recursive shared library MakefilesFrederic Riss2019-10-0828-221/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the secondary Makefiles we have are just a couple variable definitions and then an include of Makefile.rules. This patch removes most of the secondary Makefiles and replaces them with a direct invocation of Makefile.rules in the main Makefile. The specificities of each sub-build are listed right there on the recursive $(MAKE) call. All the variables that matter are being passed automagically by make as they have been passed on the command line. The only things you need to specify are the variables customizating the Makefile.rules logic for each image. This patch also removes most of the clean logic from those Makefiles and from Makefile.rules. The clean rule is not required anymore now that we run the testsuite in a separate build directory that is wiped with each run. The patch leaves a very crude version of clean in Makefile.rules which removes everything inside of $(BUILDDIR). It does this only when the $(BUILDDIR) looks like a sub-directory of our standard testsuite build directory to be extra safe. Reviewers: aprantl, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68558 llvm-svn: 374076
* [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-084-13/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tweak minidebuginfo-set-and-hit-breakpoint.testPavel Labath2019-10-081-5/+8
| | | | | | | | | | | On my system, llvm-objcopy was refusing to remove the .dynsym section because it was still referenced from .rela.plt. Remove that section too, and clarify that this is needed only because llvm-objcopy --only-keep-debug does not work (does not set the sections to SHT_NOBITS). Also, ensure that the test is not creating temporary files in the source tree. llvm-svn: 374046
* 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
* Fix a -Wpedantic warningPavel Labath2019-10-081-1/+1
| | | | | | namespace-closing '}' don't need ';'. llvm-svn: 374029
* Revert "ProcessInstanceInfoMatch: Don't match processes with no name if a ↵Jonas Devlieghere2019-10-082-18/+1
| | | | | | | | name match was requested" This breaks TestProcessAttach and TestHelloWorld on Darwin. llvm-svn: 374008
* test fix: TestLoadUsingPaths should use realpathLawrence D'Anna2019-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: TestLoadUsingPaths will fail if the build directory has symlinks in its path, because the real paths reported by the debugger won't match the symlink-laden paths it's expecting. This can be solved just by using os.path.realpath on the base path for the test. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68618 llvm-svn: 374007
* Fixing missing lldb-scripts rename from D68370Antonio Afonso2019-10-081-1/+1
| | | | llvm-svn: 374005
* [CMake] Add two more uses of add_lldb_test_dependencyJonas Devlieghere2019-10-083-11/+2
| | | | llvm-svn: 374000
* [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
* DWIMy filterspecs for dotest.pyLawrence D'Anna2019-10-082-19/+29
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: dotest.py currently requires a filterspec to be of the form `TestCase.test_method`. This patch makes it more flexible, so you can pass `TestModule.TestCase.test_method` or `TestModule.TestCase` or `TestCase.test_method` or just `test_method`. This makes it more convenient to just copy a test name out of the terminal after running a bunch of tests and use it as a filterspec. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere Subscribers: jingham, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68545 llvm-svn: 373997
* [CMake] Track test dependencies with add_lldb_test_dependencyJonas Devlieghere2019-10-086-38/+37
| | | | | | | | | | | | | I often use `ninja lldb-test-deps` to build all the test dependencies before running a subset of the tests with `lit --filter`. This functionality seems to break relatively often because test dependencies are tracked in an ad-hoc way acrooss cmake files. This patch adds a helper function `add_lldb_test_dependency` to unify test dependency tracking by adding dependencies to lldb-test-deps. Differential revision: https://reviews.llvm.org/D68612 llvm-svn: 373996
* [CMake] Remove stale commentJonas Devlieghere2019-10-081-2/+0
| | | | llvm-svn: 373995
* [MachO] Fix symbol merging during symtab parsing.Jonas Devlieghere2019-10-082-23/+754
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-078-214/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-22/+0
| | | | llvm-svn: 373990
* [CMake] We only want to copy the headers for macOS.Davide Italiano2019-10-071-0/+2
| | | | | | <rdar://problem/55916729> llvm-svn: 373970
* Mark constructor as default and remove implementation (NFC)Adrian Prantl2019-10-072-3/+1
| | | | llvm-svn: 373968
* [debugserver] Include the correct header.Davide Italiano2019-10-071-1/+1
| | | | | | <rdar://problem/55916729> llvm-svn: 373957
* [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
OpenPOWER on IntegriCloud