summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb] Don't process symlinks deep inside DWARFUnitPavel Labath2019-12-232-20/+12
| | | | | | | | | | | | | | | | | | | | | | Summary: This code is handling debug info paths starting with /proc/self/cwd, which is one of the mechanisms people use to obtain "relocatable" debug info (the idea being that one starts the debugger with an appropriate cwd and things "just work"). Instead of resolving the symlinks inside DWARFUnit, we can do the same thing more elegantly by hooking into the existing Module path remapping code. Since llvm::DWARFUnit does not support any similar functionality, doing things this way is also a step towards unifying llvm and lldb dwarf parsers. Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71770
* [lldb] Fix a -Wreturn-type gcc warning in ScriptInterpreter.cppPavel Labath2019-12-231-0/+1
|
* [lldb/lua] Fix bindings.test for lua-5.1Pavel Labath2019-12-231-1/+1
| | | | | string.format("%s", true) only works since lua-5.2. Make the print statement more portable.
* [lldb][NFC] Simplify ClangASTContext::GetTranslationUnitDeclRaphael Isemann2019-12-232-11/+3
| | | | | | | | | | | | | | | | | These two functions are just calling their equivalent function in ASTContext and implicitly convert the result to a DeclContext* (a parent class of TranslationUnitDecl). This leads to the absurd situation that we had to cast the result of GetTranslationUnitDecl to a TranslationUnitDecl*. The only reason we did this implicit conversion to the parent class was that the void* conversion for the CompilerDeclContext constructor was sound (which otherwise would receive a Decl* pointer when called with a TranslationUnitDecl*). Now that the CompilerDeclContext constructor is type safe we can properly implement these functions by actually returning the right type. Also deletes the static inconvenience method that was not used anywhere.
* [lldb] Add a SubsystemRAII that takes care of calling Initialize and ↵Raphael Isemann2019-12-2327-231/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Terminate in the unit tests Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630
* [lldb][NFC] Document CompilerDeclContext constructorsRaphael Isemann2019-12-231-1/+7
|
* [lldb][NFC] Make CompilerDeclContext construction type safeRaphael Isemann2019-12-239-21/+25
| | | | | | | | | | | | | | | The CompilerDeclContext constructor takes a void* pointer which means that all callers of this constructor need to first explicitly convert all pointers to clang::DeclContext*. This causes that we for example can't just pass a TranslationUnitDecl* to the constructor without first casting it to its parent class (as it inherits from both Decl and DeclContext so the void* pointer is actually a Decl*). This patch introduces a utility function in the ClangASTContext which gets rid of the requirement to cast all pointers to clang::DeclContext. Also moves all constructor calls to use this function instead which is NFC (beside the change in DWARFASTParserClangTests.cpp).
* [lldb/ScriptInterpreter] Remove can_reload which is always true (NFC)Jonas Devlieghere2019-12-227-26/+12
| | | | | | The `-r` option for `command script import` is there for legacy compatibility, however the can_reload flag is always set to true. This patch removes the flag and any code that relies on it being false.
* build: use `find_package(Python3)` rather than `PYTHON_HOME`Saleem Abdulrasool2019-12-221-0/+1
| | | | | | The behaviour of `PYTHON_HOME` can be emulated by setting `Python3_EXECUTABLE` to the absolute path instead of the custom variable now that we can find the python interpreter.
* [lldb/ScriptInterpreter] Unify error message for command script importJonas Devlieghere2019-12-224-11/+11
| | | | | Rather than checking for Python explicitly, let the script interpreter handle things and print an error if the functionality is not supported.
* build: improve python checks for WindowsSaleem Abdulrasool2019-12-222-167/+25
| | | | | | | | Require a newer CMake on Windows to use the Python3 support that is packaged in CMake. This version is able to check both 32-bit and 64-bit versions and will setup everything properly without the user needing to specify PYTHON_HOME. This enables building lldb's python bindings on Windows under Azure's CI again.
* [lldb] Remove unused CompilerDeclContext::IsStructUnionOrClassRaphael Isemann2019-12-225-20/+0
|
* [LLDB] Fix building without SWIGMartin Storsjö2019-12-221-1/+3
| | | | | | | | | | | | Previously, SWIG was only a hard dependency if python bindings were enabled. Since bf03e17c570171c7a52117fe63ace89d58f328d5, scripts/CMakeLists.txt is included unconditionally, while that file adds the hard dependency on SWIG. Instead, only include that file if either python or lua bindings are enabled.
* [lldb/ScriptInterpreter] Fix stale/bogus error messagesJonas Devlieghere2019-12-213-2/+15
| | | | | Fix the nonsensical error messages for when breakpoint and watchpoint callbacks are not supported.
* [lldb/Commands] Honor the scripting language passed (2/2)Jonas Devlieghere2019-12-211-14/+26
| | | | | | This ensures that watchpoint command honors the scripting language passed with `-s`. Currently the argument ignores the actual language and only uses it to differentiate between lldb and script commands.
* [lldb/Lua] Add missing boiler plate to ScriptInterpreter.Jonas Devlieghere2019-12-213-17/+14
| | | | | | - Fix enum entry order. - Fix missing enum case in CommandObjectBreakpointCommand. - Add Lua entry to swtich in LanguageToString and simplify the code.
* [lldb/Commands] Use the default scripting langauge for BP functionsJonas Devlieghere2019-12-211-1/+4
| | | | | When a function is used as a breakpoint command, use to the debugger's default scripting language, unless a language is explicitly specified.
* [lldb/Commands] Honor the scripting language passedJonas Devlieghere2019-12-212-2/+13
| | | | | | This ensures that breakpoint command honors the scripting language passed with `-s`. Currently the argument ignores the actual language and only uses it to differentiate between lldb and script commands.
* [lldb/Commands] Fix bogus enum entry and add Lua (NFC)Jonas Devlieghere2019-12-211-5/+12
| | | | | Fixes a bogus enum value for the scripting language options, adds an entry for Lua and refactored the code to use an exhaustive switch.
* [lldb/Core] Support asking the debugger for a specific script interpreterJonas Devlieghere2019-12-212-9/+16
| | | | | | | | | Rather than holding on to one script interpreter, it should be possible to request a script interpreter for a specific scripting language. The GetScriptInterpreter method now takes an optional scripting language argument. (NFC)
* [Lldb/Lua] Persist Lua state across script interpreter calls.Jonas Devlieghere2019-12-215-9/+24
| | | | | | Don't create a new lua state on every operation. Share a single state across the lifetime of the script interpreter. Add simple locking to prevent two threads from modifying the state concurrently.
* [lldb] Fix windows build after getASTContext() changeRaphael Isemann2019-12-211-3/+2
|
* [lldb][NFC] Return a reference from ClangASTContext::getASTContext and ↵Raphael Isemann2019-12-2118-735/+682
| | | | | | | | | | | remove dead nullptr checks ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a while that the ASTContext is not a nullptr. This causes that we still have a lot of code that is doing nullptr checks on the result of getASTContext() which is all unreachable code. This patch changes the return value to a reference to make it clear this can't be a nullptr and deletes all the nullptr checks.
* [Lldb/Lua] Generate Lua BindingsJonas Devlieghere2019-12-218-28/+107
| | | | | | | | | | | This patch uses SWIG to generate the Lua bindings for the SB API. It covers most of the API, but some methods require a type map similar to Python. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71235
* [lldb][NFC] Remove all ASTContext getter wrappers from ClangASTContextRaphael Isemann2019-12-217-120/+59
| | | | | | | | | | | | Their naming is misleading as they only return the ClangASTContext-owned variables. For ClangASTContext instances constructed for a given clang::ASTContext they silently generated duplicated instances (e.g., a second IdentifierTable) that were essentially unusable. This removes all these getters as they are anyway not very useful in comparison to just calling the clang::ASTContext getters. The initialization code has been moved to the CreateASTContext initialization method so that all code for making our own clang::ASTContext is in one place.
* [lldb] disable thread-step-out-ret-addr-check on windowsPavel Labath2019-12-211-0/+1
| | | | I'm unable to get this test working there.
* [lldb] One more attempt to fix thread-step-out-ret-addr-check on windowsPavel Labath2019-12-211-0/+1
|
* [lldb] Force the preprocessor to run in thread-step-out-ret-addr-check.testPavel Labath2019-12-211-1/+1
| | | | It does not seem to run automatically on windows.
* [lldb] Fix -Wstringop-truncation in PythonReadline.cppPavel Labath2019-12-211-1/+1
| | | | | The size is known and the truncation is deliberate -- use memcpy instead of strncpy.
* [lldb] [testsuite] Fix Linux fail: Unwind/thread-step-out-ret-addr-check.testJan Kratochvil2019-12-212-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | D71372 introduced: `Unwind/thread-step-out-ret-addr-check.test` failing on Fedora 30 Linux x86_64. [lldb] Add additional validation on return address in 'thread step-out' https://reviews.llvm.org/D71372 One problem is the underscored `_nonstandard_stub` in the `.s` file but not in the LLDB command: (lldb) breakpoint set -n nonstandard_stub Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) process launch Process 21919 exited with status = 0 (0x00000000) Process 21919 launched: '/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/test/Unwind/Output/thread-step-out-ret-addr-check.test.tmp' (x86_64) (lldb) thread step-out error: invalid thread (lldb) _ Another problem is that Fedora Linux has executable stack by default and all programs indicate non-executable stack by `PT_GNU_STACK`, after fixing the underscore I was getting: (lldb) thread step-out Process 22294 exited with status = 0 (0x00000000) (lldb) _ A different approach was tried as: [lldb] Refactor thread-step-out-ret-addr-check test to use .data instead of stack variable https://reviews.llvm.org/D71789 Differential revision: https://reviews.llvm.org/D71784
* [lldb] Fix ARM32 inferior callsJan Kratochvil2019-12-216-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
* [lldb/test] Update !DIModule for isysroot renameJonas Devlieghere2019-12-201-2/+2
| | | | | The isysroot field in DIModule was renamed to sysroot but the test in LLDB wasn't updated. This fixes that.
* [lldb/test] Skip editline tests when LLDB_ENABLE_LIBEDIT is off.Jonas Devlieghere2019-12-205-0/+8
| | | | | Add a new decorator that checks if LLDB was build with editline support and mark the relevant tests as skipped when that's not the case.
* [lldb] Expose more optional dependencies through GetBuildConfiguration()Jonas Devlieghere2019-12-201-0/+12
| | | | | Expose all the externally-observable optional dependencies through SBDebugger::GetBuildConfiguration().
* [lldb/CMake] Don't use return() from macro()Jonas Devlieghere2019-12-201-4/+7
| | | | | | | | | > A macro is executed as if the macro body were pasted in place of the > calling statement. This has the consequence that a return() in a macro > body does not just terminate execution of the macro After converting from a function() to a macro(), the return() became invalid. This modifies the control flow to elude the return.
* Re-land "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-204-46/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* Revert "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-203-47/+44
| | | | This is failing on both the Windows and Debian bot.
* Temporarily restrict the test for D71372 to darwin till we fix it on other ↵Jim Ingham2019-12-201-1/+1
| | | | systems.
* [lldb/CMake] Change how we deal with optional dependenciesJonas Devlieghere2019-12-203-44/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysrootAdrian Prantl2019-12-201-1/+1
| | | | | | | | | | | | This is a purely cosmetic change that is NFC in terms of the binary output. I bugs me that I called the attribute DW_AT_LLVM_isysroot since the "i" is an artifact of GCC command line option syntax (-isysroot is in the category of -i options) and doesn't carry any useful information otherwise. This attribute only appears in Clang module debug info. Differential Revision: https://reviews.llvm.org/D71722
* [lldb/Lua] Implement a Simple Lua Script Interpreter PrototypeJonas Devlieghere2019-12-2014-12/+235
| | | | | | | | | | | | | | | This implements a very elementary Lua script interpreter. It supports running a single command as well as running interactively. It uses editline if available. It's still missing a bunch of stuff though. Some things that I intentionally ingored for now are that I/O isn't properly hooked up (so every print goes to stdout) and the non-editline support which is not handling a bunch of corner cases. The latter is a matter of reusing existing code in the Python interpreter. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71234
* In 'thread step-out' command, only insert a breakpoint in executable memory.Jim Ingham2019-12-204-1/+63
| | | | | | | | | Previously, if the current function had a nonstandard stack layout/ABI, and had a valid data pointer in the location where the return address is usually located, data corruption would occur when the breakpoint was written. This could lead to an incorrectly reported crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts. Differential Revision: https://reviews.llvm.org/D71372
* ThreadPlanTracer::TracingStarted can't call virtual methods on Thread.Jim Ingham2019-12-201-4/+5
| | | | | | | | | | TracingStarted gets called in the Thread constructor, which means you can't call a virtual method of the class. So delay setting up the m_register_values till you need them. NFC as lldb just crashes if you don't do this. The thread tracing is an only occasionally useful feature, and it only sort of works. I'm not adding tests etc. at this point, I'm just poking at it a bit. If I get it working better I'll write tests and so forth.
* [lldb][NFC] Remove utility methods in TestClangASTImporterRaphael Isemann2019-12-201-35/+8
| | | | | We have a central header for all these methods so we can just use those for creating ClangASTContexts.
* [lldb][NFC] Remove redundant ASTContext args to CopyDecl/DeportDeclRaphael Isemann2019-12-206-28/+14
| | | | | | We already pass a Decl here and the additional ASTContext needs to match the Decl. We might as well just pass the Decl and then extract the ASTContext from that.
* [lldb/cmake] Delete LLDB_LINKER_SUPPORTS_GROUPSPavel Labath2019-12-201-6/+0
| | | | The variable is unused.
* [lldb] Fix an unused variable warningPavel Labath2019-12-201-1/+1
|
* [lldb/cmake] Remove support for LLDB_DISABLE_CURSESPavel Labath2019-12-201-6/+1
| | | | The buildbot which necessitated this is fixed.
* [lldb][NFC] Move utility functions from ClangASTImporter and ↵Raphael Isemann2019-12-204-84/+129
| | | | ClangExpressionDeclMap to own header
* [lldb] Put the headers in unittests/TestingSupport/ into modulesRaphael Isemann2019-12-201-0/+11
|
OpenPOWER on IntegriCloud