summaryrefslogtreecommitdiffstats
path: root/lldb/source/Symbol
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix for clang interface updateMikael Nilsson2018-12-131-1/+1
| | | | | | | | | FunctionProtoType.TypeQuals is now a Qualifiers object instead of an integer. The related clang commit: r349019 llvm-svn: 349020
* [ast] CreateParameterDeclaration should use an appropriate DeclContext.Zachary Turner2018-12-121-3/+3
| | | | | | | | | | | | | | | | | | Previously CreateParameterDeclaration was always using the translation unit DeclContext. We would later go and add parameters to the FunctionDecl, but internally clang makes a copy when you do this, and we'd end up with ParmVarDecl's at the global scope as well as in the function scope. This fixes the issue. It's hard to say whether this will introduce a behavioral change in name lookup, but I know there have been several hacks introduced in previous years to deal with collisions between various types of variables, so there's a chance that this patch could obviate one of those hacks. Differential Revision: https://reviews.llvm.org/D55571 llvm-svn: 348941
* Rename ObjectFile::GetHeaderAddress to GetBaseAddressPavel Labath2018-12-111-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This function was named such because in the case of MachO files, the mach header is located at this address. However all (most?) usages of this function were not interested in that fact, but the fact that this address is used as the base address for expressing various relative addresses in the object file. For other object file formats, this name is not appropriate (and it's probably the reason why this function was not implemented in these classes). In the ELF case the ELF header will usually end up at this address, but this is a result of the linker optimizing the file layout and not a requirement of the spec. For COFF files, I believe the is no header located at this address either. Reviewers: clayborg, jasonmolenda, amccarth, lemo, stella.stamenova Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D55422 llvm-svn: 348849
* Fix undefined behavior in Variable.hZachary Turner2018-12-111-1/+2
| | | | | | | | | | | | m_loc_is_constant_data was uninitialized, so unless someone explicitly called SetLocIsConstantData(), this would be UB. I think every existing call-site would always call the proper function to initialize the value, so there were no existing bugs, but I encountered this when I tried to use it without calling this function and encountered this. llvm-svn: 348813
* Re-commit "Introduce ObjectFileBreakpad"Pavel Labath2018-12-101-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r348592, which was reverted due to a failing test on macos. The issue was that I was passing a null pointer for the "CreateMemoryInstance" callback when registering ObjectFileBreakpad, which caused crashes when attemping to load modules from memory. The correct thing to do is to pass a callback which always returns a null pointer (as breakpad files are never loaded in inferior memory). It turns out that there is only one test which exercises this code path, and it's mac-only, so I've create a new test which should run everywhere (except windows, as one cannot delete an executable which is being run). Unfortunately, this test still fails on linux for other reasons, but at least it gives us something to aim for. The original commit message was: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348773
* Revert "Introduce ObjectFileBreakpad"Shafik Yaghmour2018-12-071-60/+0
| | | | | | | | This reverts commit 5e056e624cc57bb22a4c29a70b522783c6242293. Reverting because this lldb cmake bot: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/ llvm-svn: 348629
* Introduce ObjectFileBreakpadPavel Labath2018-12-071-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348592
* [Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov2018-11-301-9/+18
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file, not only in a symtab. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee. Reviewers: zturner, asmith, labath, clayborg, espindola Reviewed By: clayborg Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 347960
* Revert r347673 "Catch up with EvaluateAsInt() clang API change."Hans Wennborg2018-11-281-5/+6
| | | | | | r347417 was re-committed in Clang. llvm-svn: 347758
* Catch up with EvaluateAsInt() clang API change.Davide Italiano2018-11-271-6/+5
| | | | llvm-svn: 347673
* Add support for the Dylan language to ClangASTContextBruce Mitchener2018-11-271-1/+3
| | | | | | | | | | | | | | | | | | | Summary: This change adds eLanguageTypeDylan to the set of languages supported by ClangASTContext. Debug info generated by the Open Dylan compiler's LLVM back-end was designed to be compatible with C debug info. Patch by Peter Housel. Reviewers: clayborg Reviewed By: clayborg Subscribers: brucem, lldb-commits, aprantl Differential Revision: https://reviews.llvm.org/D54886 llvm-svn: 347637
* [ASTImporter] Set MustBuildLookupTable on PrimaryContextGabor Marton2018-11-261-1/+1
| | | | | | | | | | | | Summary: SetMustBuildLookupTable() must always be called on a primary context. Reviewers: labath, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411 Differential Revision: https://reviews.llvm.org/D54863 llvm-svn: 347575
* Update call to EvaluateAsInt() to the new syntax.Bill Wendling2018-11-211-5/+6
| | | | llvm-svn: 347418
* Revert 347365, its prerequisite 347364 got reverted.Nico Weber2018-11-211-6/+5
| | | | llvm-svn: 347391
* Update call to EvaluateAsInt() to the new syntax.Bill Wendling2018-11-201-5/+6
| | | | llvm-svn: 347365
* Fix a use-after-free of the ABI plugin.Zachary Turner2018-11-151-8/+9
| | | | | | | | | | | This was introduced in r346775. Previously the ABI shared_ptr was declared as a function local static meaning it would live forever. After the change, someone has to create a strong reference to it or it will go away. In this code, we were calling ABI::FindPlugin(...).get(), so it was being immediately destroyed and we were holding onto a dangling pointer. llvm-svn: 346932
* [LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".George Rimar2018-11-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
* Revert r346848 "[LLDB] - Support the single file split DWARF."George Rimar2018-11-141-4/+0
| | | | | | | It broke BB: http://green.lab.llvm.org/green/job/lldb-cmake/12522/testReport/junit/LLDB/Breakpoint/single_file_split_dwarf_test/ llvm-svn: 346853
* [LLDB] - Support the single file split DWARF.George Rimar2018-11-141-0/+4
| | | | | | | | | | | | | | | | | | DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52296 llvm-svn: 346848
* Re-land "Extract construction of DataBufferLLVM into FileSystem"Jonas Devlieghere2018-11-121-7/+7
| | | | | | This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
* Revert "Extract construction of DataBufferLLVM into FileSystem"Davide Italiano2018-11-121-7/+7
| | | | | | It broke the lldb sanitizer bots. llvm-svn: 346694
* [ClangASTContext] Extract VTable pointers from C++ objectsAleksandr Urakov2018-11-121-74/+122
| | | | | | | | | | | | | | | | | | This patch processes the case of retrieving a virtual base when the object is already read from the debuggee memory. To achieve that ValueObject::GetCPPVTableAddress was removed and was reimplemented in ClangASTContext (because access to the process is needed to retrieve the VTable pointer in general, and because this is the only place that used old version of ValueObject::GetCPPVTableAddress). This patch allows to use real object's VTable instead of searching virtual bases by offsets restored by MicrosoftRecordLayoutBuilder. PDB has no enough info to restore VBase offsets properly, so we have to read real VTable instead. Differential revision: https://reviews.llvm.org/D53506 llvm-svn: 346669
* Remove header grouping comments.Jonas Devlieghere2018-11-116-22/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Extract construction of DataBufferLLVM into FileSystemJonas Devlieghere2018-11-101-7/+7
| | | | | | | | | | This moves construction of data buffers into the FileSystem class. Like some of the previous refactorings we don't translate the path yet because the functionality hasn't been landed in LLVM yet. Differential revision: https://reviews.llvm.org/D54272 llvm-svn: 346598
* [lldb] Silence unhandled enums warning.Jorge Gorbe Moya2018-11-081-0/+14
| | | | | | | | | | | | The warning was introduced by r346392, which introduces new builtin types (to support cl_intel_device_side_avc_motion_estimation OpenCL extension). Note that this patch only inserts empty cases to silence the warning and unblock our integrate, does not aim to add support for the new types in lldb. llvm-svn: 346441
* Refactor ClangASTContext::AddEnumerationValueToEnumerationType() to remove ↵Shafik Yaghmour2018-11-081-33/+45
| | | | | | | | | | redundant parameter which can be calculated from other parameter. rdar://problem/43822994 Differential Revision: https://reviews.llvm.org/D54003 llvm-svn: 346428
* Fix (and improve) the support for C99 variable length array typesAdrian Prantl2018-11-054-16/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this: 0x00000051: DW_TAG_variable [4] DW_AT_location( fbreg -32 ) DW_AT_name( "__vla_expr" ) DW_AT_type( {0x000000d3} ( long unsigned int ) ) DW_AT_artificial( true ) ... 0x000000da: DW_TAG_array_type [10] * DW_AT_type( {0x000000cc} ( int ) ) 0x000000df: DW_TAG_subrange_type [11] DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) ) DW_AT_count( {0x00000051} ) Without this patch LLDB will naively interpret the DIE offset 0x51 as the static size of the array, which is clearly wrong. This patch extends ValueObject::GetNumChildren to query the dynamic properties of incomplete array types. See the testcase for an example: 4 int foo(int a) { 5 int vla[a]; 6 for (int i = 0; i < a; ++i) 7 vla[i] = i; 8 -> 9 pause(); // break here 10 return vla[a-1]; 11 } (lldb) fr v vla (int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3) (lldb) quit rdar://problem/21814005 Differential Revision: https://reviews.llvm.org/D53530 llvm-svn: 346165
* Remove OCaml debugger pluginJonas Devlieghere2018-11-052-671/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the OCaml debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54060 llvm-svn: 346159
* Remove Java debugger pluginJonas Devlieghere2018-11-052-1320/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Java debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54059 llvm-svn: 346158
* Remove Go debugger pluginJonas Devlieghere2018-11-052-1447/+1
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Go debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54057 llvm-svn: 346157
* Properly cast from DeclContext to Decl.Zachary Turner2018-11-051-2/+2
| | | | | | | Apparently there's a special procedure for doing this. Not following this silently breaks builds. llvm-svn: 346156
* Add a target modules dump ast command.Zachary Turner2018-11-051-1/+6
| | | | | | | | | | This is useful for investigating the clang ast as you reconstruct it via by parsing debug info. It can also be used to write tests against. Differential Revision: https://reviews.llvm.org/D54072 llvm-svn: 346149
* Revert "[Symbol] Search symbols with name and type in a symbol file"Davide Italiano2018-11-021-21/+9
| | | | | | It broke MacOS buildbots. llvm-svn: 346045
* [Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov2018-11-021-9/+21
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee. Reviewers: zturner, asmith, labath, clayborg, espindola Reviewed By: clayborg Subscribers: emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 345957
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-014-6/+6
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* [FileSystem] Remove Exists() from FileSpecJonas Devlieghere2018-11-011-2/+2
| | | | | | | | | This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53845 llvm-svn: 345854
* [FileSystem] Remove GetByteSize() from FileSpecJonas Devlieghere2018-11-011-2/+3
| | | | | | | | | This patch removes the GetByteSize method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53788 llvm-svn: 345812
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-1/+1
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* [x86] Fix issues with a realigned stack in MSVC compiled applicationsAleksandr Urakov2018-10-301-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes issues with a stack realignment. MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned stack - one is used for access to function parameters, while another is used for access to locals. To support this the patch: - adds an alternative frame pointer (`ebx`); - considers stack realignment instructions (e.g. `and esp, -32`); - along with CFA (Canonical Frame Address) which point to the position next to the saved return address (or to the first parameter on the stack) introduces AFA (Aligned Frame Address) which points to the position of the stack pointer right after realignment. AFA is used for access to registers saved after the realignment (see the test); Here is an example of the code with the realignment: ``` struct __declspec(align(256)) OverAligned { char c; }; void foo(int foo_arg) { OverAligned oa_foo = { 1 }; auto aaa_foo = 1234; } void bar(int bar_arg) { OverAligned oa_bar = { 2 }; auto aaa_bar = 5678; foo(1111); } int main() { bar(2222); return 0; } ``` and here is the `bar` disassembly: ``` push ebx mov ebx, esp sub esp, 8 and esp, -100h add esp, 4 push ebp mov ebp, [ebx+4] mov [esp+4], ebp mov ebp, esp sub esp, 200h mov byte ptr [ebp-200h], 2 mov dword ptr [ebp-4], 5678 push 1111 ; foo_arg call j_?foo@@YAXH@Z ; foo(int) add esp, 4 mov esp, ebp pop ebp mov esp, ebx pop ebx retn ``` Reviewers: labath, zturner, jasonmolenda, stella.stamenova Reviewed By: jasonmolenda Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D53435 llvm-svn: 345577
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-252-3/+3
| | | | | | | | | | This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
* Don't type-erase the SymbolContextItem enumeration.Zachary Turner2018-10-253-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is. The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly. This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean. Differential Revision: https://reviews.llvm.org/D53597 llvm-svn: 345313
* [NFC] Refactor SetBaseClasses and DeleteBaseClasses.Zachary Turner2018-10-251-26/+24
| | | | | | | | | | | | | | | | | | | | | | We currently had a 2-step process where we had to call SetBaseClassesForType and DeleteBaseClasses. Every single caller followed this exact 2-step process, and there was manual memory management going on with raw pointers. We can do better than this by storing a vector of unique_ptrs and passing this around. This makes for a cleaner API, and we only need to call one method so there is no possibility of a user forgetting to call DeleteBaseClassSpecifiers. In addition to this, it also makes for a *simpler* API. Part of why I wanted to do this is because when I was implementing the native PDB interface I had to spend some time understanding exactly what I was deleting and why. ClangAST has significant mental overhead associated with it, and reducing the API surface can go along way to making it simpler for people to understand. Differential Revision: https://reviews.llvm.org/D53590 llvm-svn: 345312
* Change two methods from const char* to StringRef [NFC].Zachary Turner2018-10-231-34/+43
| | | | llvm-svn: 345055
* [LLDB] - Implement the support for the .debug_loclists section.George Rimar2018-10-231-0/+1
| | | | | | | | | | | This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
* [DWARF] Use a function-local offset for AT_call_return_pcVedant Kumar2018-10-221-2/+1
| | | | | | | | | | | | | | | | | | | Logs provided by @stella.stamenova indicate that on Linux, lldb adds a spurious slide offset to the return PC it loads from AT_call_return_pc attributes (see the list thread: "[PATCH] D50478: Add support for artificial tail call frames"). This patch side-steps the issue by getting rid of the load address calculation in lldb's CallEdge::GetReturnPCAddress. The idea is to have the DWARF writer emit function-local offsets to the instruction after a call. I.e. return-pc = label-after-call-insn - function-entry. LLDB can simply add this offset to the base address of a function to get the return PC. Differential Revision: https://reviews.llvm.org/D53469 llvm-svn: 344960
* [SymbolFile] Add the module lock where necessary and assert that we own it.Jonas Devlieghere2018-10-221-0/+20
| | | | | | | | | | | | | | | As discussed with Greg at the dev meeting, we need to ensure we have the module lock in the SymbolFile. Usually the symbol file is accessed through the symbol vendor which ensures that the necessary locks are taken. However, there are a few methods that are accessed by the expression parser and were lacking the lock. This patch adds the locking where necessary and everywhere else asserts that we actually already own the lock. Differential revision: https://reviews.llvm.org/D52543 llvm-svn: 344945
* [LLDB] - Add basic support for .debug_rnglists section (DWARF5)George Rimar2018-10-101-0/+1
| | | | | | | | | This adds a basic support of the .debug_rnglists section. Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported. Differential revision: https://reviews.llvm.org/D52981 llvm-svn: 344119
* Add support for artificial tail call framesVedant Kumar2018-10-052-12/+102
| | | | | | | | | | | | | | | | This patch teaches lldb to detect when there are missing frames in a backtrace due to a sequence of tail calls, and to fill in the backtrace with artificial tail call frames when this happens. This is only done when the execution history can be determined from the call graph and from the return PC addresses of calls on the stack. Ambiguous sequences of tail calls (e.g anything involving tail calls and recursion) are detected and ignored. Depends on D49887. Differential Revision: https://reviews.llvm.org/D50478 llvm-svn: 343900
* [lldb] Start a new line for the next output if there are no symbols in the ↵Aaron Smith2018-10-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | current symtab Summary: If there is no newline the "lldb" prompt could be on the wrong line. To reproduce the missing newline you can do 'image dump smytab' on any binary. Previously Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0(lldb) Now Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0 (lldb) Reviewers: zturner, aleksandr.urakov, lldb-commits Subscribers: abidh Differential Revision: https://reviews.llvm.org/D52627 llvm-svn: 343497
* [PDB] Restore the calling convention from PDBAleksandr Urakov2018-09-261-1/+3
| | | | | | | | | | | | | | | | | | | Summary: This patch implements restoring of the calling convention from PDB. It is necessary for expressions evaluation, if we want to call a function of the debuggee process with a calling convention other than ccall. Reviewers: clayborg, zturner, labath, asmith Reviewed By: clayborg Subscribers: teemperor, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D52501 llvm-svn: 343084
OpenPOWER on IntegriCloud