summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb] Add sanity check to CreateDeclContext and fixed illformed ↵Raphael Isemann2019-12-231-1/+3
| | | | | | | | | | | | | | | | | | | | | CompilerContext in ClangExpressionDeclMap. This adds a check that the ClangASTContext actually fits to the DeclContext that we want to create a CompilerDeclContext for. If the ClangASTContext (and its associated ASTContext) does not fit to the DeclContext (that is, the DeclContext wasn't created by the ASTContext), all computations using this malformed CompilerDeclContext will yield unpredictable results. Also fixes the only place that actually hits this assert which is the construction of a CompilerDeclContext in ClangExpressionDeclMap where we pass an unrelated ASTContext instead of the ASTContext of the current expression. I had to revert my previous change to DWARFASTParserClangTests.cpp back to using the unsafe direct construction of CompilerDeclContext as this assert won't work if the DeclContext we pass isn't a valid DeclContext in the first place.
* [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][NFC] Make CompilerDeclContext construction type safeRaphael Isemann2019-12-235-11/+8
| | | | | | | | | | | | | | | 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-223-13/+6
| | | | | | 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.
* [Lldb/Lua] Persist Lua state across script interpreter calls.Jonas Devlieghere2019-12-214-9/+21
| | | | | | 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][NFC] Return a reference from ClangASTContext::getASTContext and ↵Raphael Isemann2019-12-2110-103/+76
| | | | | | | | | | | 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-212-0/+7
| | | | | | | | | | | 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-213-8/+4
| | | | | | | | | | | | 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] 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] Fix ARM32 inferior callsJan Kratochvil2019-12-212-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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-204-12/+120
| | | | | | | | | | | | | | | 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
* [lldb][NFC] Remove redundant ASTContext args to CopyDecl/DeportDeclRaphael Isemann2019-12-202-4/+2
| | | | | | 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] Fix address computation for inline functionJohannes Altmanninger2019-12-201-3/+6
| | | | | | | | | | | | | | | | | | | | Summary: Fixes PR41237 - SIGSEGV on call expression evaluation when debugging clang When linking multiple compilation units that define the same functions, the functions is merged but their debug info is not. This ignores debug info entries for functions in a non-executable sections; those are functions that were definitely dropped by the linker. Reviewers: spyffe, clayborg, jasonmolenda Reviewed By: clayborg Subscribers: labath, aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71487
* [lldb/Lua] Add Boilerplate for a Lua Script InterpreterJonas Devlieghere2019-12-194-0/+129
| | | | | | | | | | | This adds the boilerplate necessary to support the Lua script interpreter. The interpreter is not functional yet and just reports that it's not implemented. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71232
* make err msg in MachSymtabSectionInfo::GetSection clear about the fileJason Molenda2019-12-181-2/+8
| | | | | | This error message didn't specify which file was malformed, so there's some hunting-around required if it comes up. We have the filename; include it in the error message.
* [lldb/MachO] "Fix" intentional out-of-bounds error (NFC)Jonas Devlieghere2019-12-182-6/+8
| | | | | | | Remove the hack that populates the cpsr register in the gpr struct by writing past the end of the array. This was tripping up ASan. Patch by: Reva Cuthbertson
* [lldb][NFC] Add unit test for persistent variable lookup with ↵Raphael Isemann2019-12-182-10/+26
| | | | | | | | | ClangExpressionDeclMap This adds a unit test for looking up persistent declarations in the scratch AST context. Also adds the `GetPersistentDecl` hook to the ClangExpressionDeclMap that this unit test can emulate looking up persistent variables without having a lldb_private::Target.
* [lldb][NFC] Use StringRef in CreateRecordType and CreateObjCClassRaphael Isemann2019-12-173-7/+6
|
* [lldb][NFC] Rename ClangASTImporter::InsertRecordDecl to SetRecordLayout and ↵Raphael Isemann2019-12-173-4/+4
| | | | | | | document it This function is just setting the layout for the given RecordDecl so the current name is not very descriptive. Also add some documentation for it.
* [lldb][NFC] Allow creating ClangExpressionDeclMap and ClangASTSource without ↵Raphael Isemann2019-12-176-19/+47
| | | | | | | | | | a Target and add basic unit test The ClangExpressionDeclMap should be testable from a unit test. This is currently impossible as they have both dependencies on Target/ExecutionContext from their constructor. This patch allows constructing these classes without an active Target and adds the missing tests for running without a target that we can do at least a basic lookup test without crashing.
* [lldb] Remove modern-type-lookupRaphael Isemann2019-12-177-283/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup. This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around for now). The motivation for this is that I don't think that the current approach of implementing modern-type-lookup will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has so far made the transition work much more complicated than it has to be. A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring and actually testing the existing code we have. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html Reviewers: shafik, martong Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss Tags: #lldb Differential Revision: https://reviews.llvm.org/D71562
* [lldb][NFC] Remove all unnecessary includes for ClangASTSourceCommon.hRaphael Isemann2019-12-175-5/+3
| | | | | These files only need the definition of ClangASTMetadata (which was previously in the ClangASTSourceCommon.h) or don't need the include at all.
* [lldb] Add support for calling objc_direct methods from LLDB's expression ↵Raphael Isemann2019-12-172-1/+7
| | | | | | | | | | | | | | | | | | | | | evaluator. Summary: D69991 introduced `__attribute__((objc_direct))` that allows directly calling methods without message passing. This patch adds support for calling methods with this attribute to LLDB's expression evaluator. The patch can be summarised in that LLDB just adds the same attribute to our module AST when we find a method with `__attribute__((objc_direct))` in our debug information. Reviewers: aprantl, shafik Reviewed By: shafik Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71196
* [lldb][NFC] Remove all overloads of Copy/DeportType in ClangASTImporterRaphael Isemann2019-12-162-7/+3
| | | | | | | The overloads that don't take a CompilerType serve no purpose as we always have a CompilerType in the scope where we call them. Instead just call the overload that takes a CompilerType and delete the now unused other overloaded methods.
* [lldb][NFC] Remove ClangASTImporter::ResolveDeclOriginRaphael Isemann2019-12-162-37/+24
| | | | ResolveDeclOrigin was just an inconvenience method around GetDeclOrigin.
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-139-20/+14
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* LanguageRuntime: Simplify NSException::GetSummary() outputMed Ismail Bennani2019-12-131-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Right now, NSException::GetSummary() has the following output: "name: $exception_name - reason: $exception_reason" It would be better to simplify the output by removing the name and only showing the exception's reason. This way, annotations would look nicer in the editor, and would be a shorter summary in the Variables Inspector. Accessing the exception's name can still be done by expanding the NSException object in the Variables Inspector. rdar://54770115 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71311 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_POSIXJonas Devlieghere2019-12-137-12/+12
| | | | | Rename LLDB_DISABLE_POSIX to LLDB_ENABLE_POSIX and use cmakedefine01 for consistency.
* [lldb][NFC] Make metadata tracking type safeRaphael Isemann2019-12-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: LLDB associates additional information with Types and Declarations which it calls ClangASTMetadata. ClangASTMetadata is stored by the ClangASTSourceCommon which is implemented by having a large map of `void *` keys to associated `ClangASTMetadata` values. To make this whole mechanism even unsafer we also decided to use `clang::Decl *` as one of pointers we throw in there (beside `clang::Type *`). The Decl class hierarchy uses multiple inheritance which means that not all pointers have the same address when they are implicitly converted to pointers of their parent classes. For example `clang::Decl *` and `clang::DeclContext *` won't end up being the same address when they are implicitly converted from one of the many Decl-subclasses that inherit from both. As we use the addresses as the keys in our Metadata map, this means that any implicit type conversions to parent classes (or anything else that changes the addresses) will break our metadata tracking in obscure ways. Just to illustrate how broken this whole mechanism currently is: ```lang=cpp // m_ast is our ClangASTContext. Let's double check that from GetTranslationUnitDecl // in ClangASTContext and ASTContext return the same thing (one method just calls the other). assert(m_ast->GetTranslationUnitDecl() == m_ast->getASTContext()->getTranslationUnitDecl()); // Ok, both methods have the same TU*. Let's store metadata with the result of one method call. m_ast->SetMetadataAsUserID(m_ast->GetTranslationUnitDecl(), 1234U); // Retrieve the same Metadata for the TU by using the TU* from the other method... which fails? EXPECT_EQ(m_ast->GetMetadata(m_ast->getASTContext()->getTranslationUnitDecl())->GetUserID(), 1234U); // Turns out that getTranslationUnitDecl one time returns a TranslationUnitDecl* but the other time // we return one of the parent classes of TranslationUnitDecl (DeclContext). ``` This patch splits up the `void *` API into two where one does the `clang::Type *` tracking and one the `clang::Decl *` mapping. Type and Decl are disjoint class hierarchies so there is no implicit conversion possible that could influence the address values. I had to change the storing of `clang::QualType` opaque pointers to their `clang::Type *` equivalents as opaque pointers are already `void *` pointers to begin with. We don't seem to ever set any qualifier in any of these QualTypes to this conversion should be NFC. Reviewers: labath, shafik, aprantl Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71409
* [Target] Remove Target::GetScratchClangASTContextAlex Langford2019-12-1223-73/+123
| | | | | | | Target doesn't really need to know about ClangASTContext more than any other TypeSystem. We can create a method ClangASTContext::GetScratch for anything who needs a ClangASTContext specifically instead of just a generic TypeSystem.
* [lldb/Core] Add missing include (2/2)Jonas Devlieghere2019-12-121-0/+2
| | | | This got flagged by the debian buildbot.
* [lldb/CMake] Rename LLDB_DISABLE_LIBEDIT to LLDB_ENABLE_LIBEDITJonas Devlieghere2019-12-122-3/+3
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71380
* [lldb/DWARF] Fix v5 location lists for dwo filesPavel Labath2019-12-122-1/+8
| | | | | Dwo files don't have a DW_AT_loclists_base -- set one explicitly. Also, make sure we use the correct location list flavour for v5.
* [lldb] Remove ClangASTMetricsRaphael Isemann2019-12-122-17/+0
| | | | | | | | | | | | | | Summary: Not once have I looked at these numbers in a log and considered them useful. Also this should not have been implemented via an unguarded list of globals. Reviewers: martong, shafik Reviewed By: shafik Subscribers: rnkovacs, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71336
* return-object-by-reference ("non trivial") xfail on arm64 in TestTrivialABI.pyJason Molenda2019-12-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't think this test case can be handled correctly on AAPCS64. The ABI says that the caller passes the address of the return object in x8. x8 is a caller-spilled (aka "volatile") register, and the function is not required to preserve x8 or to copy the address back into x8 on function exit like the SysV x86_64 ABI does with rax. (from aapcs64: "there is no requirement for the callee to preserve the value stored in x8") From my quick reading of ABISysV_arm64, I worry that it may actually be using the value in x8 at function exit, assuming it still has the address of the return object - if (is_return_value) { // We are assuming we are decoding this immediately after returning from // a function call and that the address of the structure is in x8 reg_info = reg_ctx->GetRegisterInfoByName("x8", 0); This will work on trivial test programs / examples, but if the function does another function call, or overwrites x8 as a scratch register, lldb will provide incorrect values to the user. ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value as unavailable so we're providing incorrect values to the user all the time. I expect my fix will be to make ABIMacOSX_arm64 flag the return value as unretrievable, unless I've misread the ABI.
* [lldb][NFC] Remove dead metadata code in ClangASTSourceProxyRaphael Isemann2019-12-111-12/+0
|
* [lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistxPavel Labath2019-12-115-3/+42
| | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for DWARF5 location lists which are specified indirectly, via an index into the debug_loclists offset table. This includes parsing the DW_AT_loclists_base attribute which determines the location of this offset table, and support for new form DW_FORM_loclistx which is used in conjuction with DW_AT_location to refer to the location lists in this way. The code uses the llvm class to parse the offset information, and I've also tried to structure it similarly to how the relevant llvm functionality works. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71268
* Revert "Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support ↵Eric Christopher2019-12-105-23/+36
| | | | | | | | | multiple GDB remotes" On multiple retry this issue won't duplicate - will revisit with author if duplication works again. This reverts commit c9e0b354e2749ce7ab553974692cb35c8651a869.
* Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support multiple GDB ↵Eric Christopher2019-12-105-36/+23
| | | | | | | | | remotes This was causing a crash in opt+assert builds on linux and a follow-up message was posted. This reverts commit e81268d03e73aef4f9c7bd8ece8ad02f5b017dcf
* [lldb/Host] Use Host/Config.h entries instead of a global define.Jonas Devlieghere2019-12-108-12/+16
| | | | | | | | | | | As suggested by Pavel in a code review: > Can we replace this (and maybe python too, while at it) with a > Host/Config.h entry? A global definition means that one has to > recompile everything when these change in any way, whereas in > practice only a handful of files need this.. Differential revision: https://reviews.llvm.org/D71280
* [lldb/Reproducers] Support multiple GDB remotesJonas Devlieghere2019-12-105-23/+36
| | | | | | | | | | | | | | | | When running the test suite with always capture on, a handful of tests are failing because they have multiple targets and therefore multiple GDB remote connections. The current reproducer infrastructure is capable of dealing with that. This patch reworks the GDB remote provider to support multiple GDB remote connections, similar to how the reproducers support shadowing multiple command interpreter inputs. The provider now keeps a list of packet recorders which deal with a single GDB remote connection. During replay we rely on the order of creation to match the number of packets to the GDB remote connection. Differential revision: https://reviews.llvm.org/D71105
* [LLDB] [PECOFF] Make sure to set the address byte size in m_data after ↵Martin Storsjö2019-12-101-0/+1
| | | | | | | | | | | | | parsing headers If not set, the address byte size was implied to be the one of the host process. This allows reverting the functional change from 31087b2ae9154, since now PECOFF does the same as ELF and MachO wrt setting both byte order and address size on m_data within ParseHeader. Differential Revision: https://reviews.llvm.org/D71108
* [lldb][CMake] Fix build for the case of custom libedit installationTatyana Krasnukha2019-12-091-0/+11
|
* [lldb] Improve/fix base address selection in location listsPavel Labath2019-12-092-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Lldb support base address selection entries in location lists was broken for a long time. This wasn't noticed until llvm started producing these kinds of entries more frequently with r374600. In r374769, I made a quick patch which added sufficient support for them to get the test suite to pass. However, I did not fully understand how this code operates, and so the fix was not complete. Specifically, what was lacking was the ability to handle modules which were not loaded at their preferred load address (for instance, due to ASLR). Now that I better understand how this code works, I've come to the conclusion that the current setup does not provide enough information to correctly process these entries. In the current setup the location lists were parameterized by two addresses: - the distance of the function start from the start of the compile unit. The purpose of this was to make the location ranges relative to the start of the function. - the actual address where the function was loaded at. With this the function-start-relative ranges can be translated to actual memory locations. The reason for the two values, instead of just one (the load bias) is (I think) MachO, where the debug info in the object files will appear to be relative to the address zero, but the actual code it refers to can be moved and reordered by the linker. This means that the location lists need to be "linked" to reflect the locations in the actual linked file. These two bits of information were enough to correctly process location lists which do not contain base address selection entries (and so all entries are relative to the CU base). However, they don't work with them because, in theory two base address can be completely unrelated (as can happen for instace with hot/cold function splitting, where the linker can reorder the two pars arbitrarily). To fix that, I split the first parameter into two: - the compile unit base address - the function start address, as is known in the object file The new algorithm becomes: - the location lists are processed as they were meant to be processed. The CU base address is used as the initial base address value. Base address selection entries can set a new base. - the difference between the "file" and "load" function start addresses is used to compute the load bias. This value is added to the final ranges to get the actual memory location. This algorithm is correct for non-MachO debug info, as there the location lists correctly describe the code in the final executable, and the dynamic linker can just move the entire module, not pieces of it. It will also be correct for MachO if the static linker preserves relative positions of the various parts of the location lists -- I don't know whether it actually does that, but judging by the lack of base address selection support in dsymutil and lldb, this isn't something that has come up in the past. I add a test case which simulates the ASLR scenario and demonstrates that base address selection entries now work correctly here. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70532
* [lldb] Support for DWARF-5 atomic typesRaphael Isemann2019-12-091-0/+4
| | | | | | | | | | | | | | | | | Summary: This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement Atomic case with the usual boilerplate. Thanks Pavel for writing the test case. Reviewers: labath, aprantl, shafik Reviewed By: labath Subscribers: jfb, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71183
* Cleanup and speedup NativeRegisterContextLinux_arm64Muhammad Omair Javaid2019-12-064-160/+130
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch simplifies register accesses in NativeRegisterContextLinux_arm64 and also adds some bare minimum caching to avoid multiple calls to ptrace during a stop. Linux ptrace returns data in the form of structures containing GPR/FPR data. This means that one single call is enough to read all GPRs or FPRs. We do that once per stop and keep reading from or writing to the buffer that we have in NativeRegisterContextLinux_arm64 class. Before a resume or detach we write all buffers back. This is tested on aarch64 thunder x1 with Ubuntu 18.04. Also tested regressions on x86_64. Reviewers: labath, clayborg Reviewed By: labath Subscribers: kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D69371
* [lldb/DWARF] Fix DW_AT_addr_base & DW_AT_low_pc interactionPavel Labath2019-12-061-4/+13
| | | | | | | | | | | | | | | | In DWARF5 DW_AT_low_pc (and DW_AT_entry_pc, and possibly others) can use DW_FORM_addrx to refer to the address indirectly. This means we need to have processed the DW_AT_addr_base attribute before we can do anything with these. Since we were processing the unit attributes serially, this created a problem in cases where the DW_AT_addr_base comes after DW_AT_low_pc -- we would end up computing the wrong unit base address, which also corrupted any values which later depended on that (for instance range lists). Clang currently always emits DW_AT_addr_base last. The fix is simple -- process DW_AT_addr_base first, regardless of its position in the attribute list.
* [lldb/DWARF] Fix DW_AT_rnglists_base handling for dwo filesPavel Labath2019-12-061-3/+5
| | | | | | | | | | the value of DW_AT_rnglists_base of the skeleton unit is for that unit alone (e.g. used in DW_AT_ranges of the unit DIE) and should not apply to the split unit. The split unit has a hardcoded range list base value -- we should initialize range list code whenever we detect a nonempty debug_rnglists.dwo section.
* [lldb/DWARF] Remove DWARFDebugRangesBase abstract classPavel Labath2019-12-062-13/+4
| | | | | now that we use llvm to parse debug_rnglists, this abstraction is not useful.
OpenPOWER on IntegriCloud