summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* [DWARF] Evaluate DW_OP_entry_valueVedant Kumar2019-09-112-3/+75
| | | | | | | | | | | | Add support for evaluating DW_OP_entry_value. This involves parsing DW_TAG_call_site_parameter and wiring the information through to the expression evaluator. rdar://54496008 Differential Revision: https://reviews.llvm.org/D67376 llvm-svn: 371668
* [Plugins/Process] Remove direct use of ClangASTContext from InferiorCallPOSIXAlex Langford2019-09-111-11/+21
| | | | | | | | | | | | | Summary: InferiorCallPOSIX directly grabs a ClangASTContext from the Target it has and does no error checking. I don't think these functions have a reason to know about clang specifically. Additionally, using `GetScratchTypeSystemForLanguage` forces us to do error checking since it returns an Expected. Differential Revision: https://reviews.llvm.org/D67427 llvm-svn: 371654
* Revert "[LLDB][ELF] Load both, .symtab and .dynsym sections"Konrad Kleine2019-09-111-18/+8
| | | | | | This reverts commit 3a4781bbf4f39a25562b4c61c9a9ab2483a96b41. llvm-svn: 371625
* Revert "[LLDB][ELF] Fixup for comments in D67390"Konrad Kleine2019-09-111-5/+6
| | | | | | This reverts commit 813f05915d29904878d926f9849ca3dbe78096af. llvm-svn: 371624
* [lldb][NFC] Make include directories in Clang expression parser a std::stringRaphael Isemann2019-09-114-11/+10
| | | | | | | | | We never compare these directories (where ConstString would be good) and essentially just convert this back to a normal string in the end. So we might as well just use std::string. Also makes it easier to unittest this code (which was the main motivation for this change). llvm-svn: 371623
* [LLDB][ELF] Fixup for comments in D67390Konrad Kleine2019-09-111-6/+5
| | | | llvm-svn: 371600
* [LLDB][ELF] Load both, .symtab and .dynsym sectionsKonrad Kleine2019-09-111-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change ensures that the .dynsym section will be parsed even when there's already is a .symtab. It is motivated because of minidebuginfo (https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html#MiniDebugInfo). There it says: Keep all the function symbols not already in the dynamic symbol table. That means the .symtab embedded inside the .gnu_debugdata does NOT contain the symbols from .dynsym. But in order to put a breakpoint on all symbols we need to load both. I hope this makes sense. My other patch D66791 implements support for minidebuginfo, that's why I need this change. Reviewers: labath, espindola, alexshap Subscribers: JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67390 llvm-svn: 371599
* [Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`Jonas Devlieghere2019-09-102-23/+30
| | | | | | | | | This removes the CleanUp class and replaces its usages with llvm's ScopeExit, which has similar semantics. Differential revision: https://reviews.llvm.org/D67378 llvm-svn: 371474
* [Symbol] Give ClangASTContext a PersistentExpressionState instead of a ↵Alex Langford2019-09-091-0/+1
| | | | | | | | | | | | | | | ClangPersistentVariables ClangASTContext doesn't use m_persistent_variables in a way specific to ClangPersistentVariables. Therefore, it should hold a unique pointer to PersistentExpressionState instead of a ClangPersistentVariablesUP. This also prevents you from pulling in a plugin header when including ClangASTContext.h Doing this exposed an implicit dependency in ObjCLanguage that was corrected by including ClangModulesDeclVendor.h llvm-svn: 371470
* [Reproducer] Disconnect when the replay server is out of packets.Jonas Devlieghere2019-09-091-3/+3
| | | | | | | | | | | | | | This is a fix for the issue described in r371144. > On more than one occasion I've found this test got stuck during replay > while waiting for a packet from debugserver when the debugger was in > the process of being destroyed. When the replay server is out of packets we should just disconnect so the debugger doesn't have to do any cleanup that it wouldn't do during capture. llvm-svn: 371459
* Fix ELF core file memory reading for PT_LOAD program headers with no p_fileszGreg Clayton2019-09-091-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this fix, ELF files might contain PT_LOAD program headers that had a valid p_vaddr, and a valid file p_offset, but the p_filesz would be zero. For example in llvm-project/lldb/test/testcases/functionalities/postmortem/elf-core/thread_crash/linux-i386.core we see: Program Headers: Index p_type p_flags p_offset p_vaddr p_paddr p_filesz p_memsz p_align ======= ---------------- ---------- ------------------ ------------------ ------------------ ------------------ ------------------ ------------------ [ 0] PT_NOTE 0x00000000 0x0000000000000474 0x0000000000000000 0x0000000000000000 0x0000000000001940 0x0000000000000000 0x0000000000000000 [ 1] PT_LOAD 0x00000005 0x0000000000002000 0x0000000008048000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000 [ 2] PT_LOAD 0x00000004 0x0000000000002000 0x000000000804b000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 3] PT_LOAD 0x00000006 0x0000000000002000 0x000000000804c000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 4] PT_LOAD 0x00000006 0x0000000000002000 0x0000000009036000 0x0000000000000000 0x0000000000000000 0x0000000000025000 0x0000000000001000 [ 5] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f63a1000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 6] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f63a2000 0x0000000000000000 0x0000000000000000 0x0000000000800000 0x0000000000001000 [ 7] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f6ba2000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 8] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f6ba3000 0x0000000000000000 0x0000000000000000 0x0000000000804000 0x0000000000001000 [ 9] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f73a7000 0x0000000000000000 0x0000000000000000 0x00000000001b1000 0x0000000000001000 [ 10] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7558000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000 [ 11] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 12] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000 [ 13] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f755e000 0x0000000000000000 0x0000000000000000 0x0000000000019000 0x0000000000001000 [ 14] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7577000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 15] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7578000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 16] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7579000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000 [ 17] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f757b000 0x0000000000000000 0x0000000000000000 0x000000000001c000 0x0000000000001000 [ 18] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7597000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 19] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7598000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 20] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f7599000 0x0000000000000000 0x0000000000000000 0x0000000000053000 0x0000000000001000 [ 21] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f75ec000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 22] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f75ed000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 23] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f75ee000 0x0000000000000000 0x0000000000000000 0x0000000000176000 0x0000000000001000 [ 24] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7764000 0x0000000000000000 0x0000000000000000 0x0000000000006000 0x0000000000001000 [ 25] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 26] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000 [ 27] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f778a000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000 [ 28] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f778c000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000 [ 29] PT_LOAD 0x00000005 0x0000000000004000 0x00000000f778e000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000 [ 30] PT_LOAD 0x00000005 0x0000000000006000 0x00000000f7790000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000 [ 31] PT_LOAD 0x00000004 0x0000000000006000 0x00000000f77b3000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 32] PT_LOAD 0x00000006 0x0000000000006000 0x00000000f77b4000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 33] PT_LOAD 0x00000006 0x0000000000006000 0x00000000ffa25000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000 Prior to this fix if users tried to read memory from one of these addresses like 0x8048000, they would end up incorrectly reading from the next memory region that actually had a p_filesz which would be 0x00000000f778c000 in this case. This fix correctly doesn't include program headers with zero p_filesz in the ProcessELFCore::m_core_aranges that is used to read memory. I found two cores files that have this same issue and added tests. Differential Revision: https://reviews.llvm.org/D67370 llvm-svn: 371457
* Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.Jason Molenda2019-09-074-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | In April via r357829, Adrian unified timeouts across lldb and set the default value high so that we wouldn't get timeouts on ASAN bots that were running under load. The library that the MacOSX SystemRuntime has functions that need to take a lock, and if that lock is held already, those functions will never complete; we're seeing the 15 second timeout being hit with inferiors that are doing a lot of enqueuing and dequeuing of libdispatch work items causing this deadlocking behavior. This patch reverts to a very short timeout for these SystemRuntime function calls, given the behavior of this library that they are calling into. When lldb is built with AddressSanitizer enabled, they will use the default 15 second timeout. tl;dr: this reverts to the previous timeouts for these SystemRuntime inf func calls. <rdar://problem/54538149> llvm-svn: 371280
* [Windows] Add support of watchpoints to `ProcessWindows`Aleksandr Urakov2019-09-067-67/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of watchpoints to the old `ProcessWindows` plugin. The `ProcessWindows` plugin uses the `RegisterContext` to set and reset watchpoints. The `RegisterContext` has some interface to access watchpoints, but it is very limited (e.g. it is impossible to retrieve the last triggered watchpoint with it), that's why I have implemented a slightly different interface in the `RegisterContextWindows`. Moreover, I have made the `ProcessWindows` plugin responsible for search of a vacant watchpoint slot, because watchpoints exist per-process (not per-thread), then we can place the same watchpoint in the same slot in different threads. With this scheme threads don't need to have their own watchpoint lists, and it simplifies identifying of the last triggered watchpoint. Reviewers: asmith, stella.stamenova, amccarth Reviewed By: amccarth Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67168 llvm-svn: 371166
* Obliterate LLDB_CONFIGURATION_BUILDANDINTEGRATIONPavel Labath2019-09-053-20/+0
| | | | | | | | | | | | | | Summary: With the XCode project gone, there doesn't seem to be anything setting this macro anymore -- and the macro wasn't doing much anyway. Reviewers: jingham, sgraenitz Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D66742 llvm-svn: 371018
* Breakpad: Basic support for STACK WIN unwindingPavel Labath2019-09-052-27/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes it possible to unwind via breakpad STACK WIN records. It is "basic" because two important features are missing: - support for the .raSearch keyword - support for multiple STACK WIN records within a single function Right now, we just reject the .raSearch records, and always pick the first record for the whole function SymbolFileBreakpad, and so I think it can serve as a good example of what is needed of the symbol file and unwinding machinery to make this work. However, it is already useful for unwinding in some situations, and it sets up the general framework for the parsing of these kinds of records, which reduces the size of the followup patches implementing the two other components. Reviewers: amccarth, rnk, markmentovai Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67067 llvm-svn: 371017
* Upstream macCatalyst support in debugserver and the macOS dynamic loaderAdrian Prantl2019-09-047-26/+119
| | | | | | | | | | | plugin. Unfortunately the test is currently XFAILed because of missing changes to the clang driver. Differential Revision: https://reviews.llvm.org/D67124 llvm-svn: 370931
* Code cleanup: Change FormattersContainer::KeyType from SP to rvalueJan Kratochvil2019-09-041-14/+8
| | | | | | | | | | | There is now std::shared_ptr passed around which is expensive for manycore CPUs. Most of the times (except for 3 cases) it is now just std::moved with no CPU locks needed. It also makes it possible to sort the keys (which is now not needed much after D66398). Differential revision: https://reviews.llvm.org/D67049 llvm-svn: 370863
* [lldb][NFC] Rename ReadRegisterValue to PrintRegisterValueRaphael Isemann2019-09-041-95/+95
| | | | | | | That was the actual name I had in mind, but it seems git didn't pick that change up when committing my previous commit. llvm-svn: 370856
* [lldb][NFC] Remove WriteRegister copy-pasta from ObjectFileMachORaphael Isemann2019-09-041-198/+119
| | | | | | | | | | | | The function had the same name as one of the member function, so it was just copied to all classes so that the lookup works. We could also give the function a more better and unique name (because it's actually printing the register value and writing to the stream, not writing to the register). Also removes the unused return value. llvm-svn: 370854
* NativeProcessLinux: Remove some register context boilerplatePavel Labath2019-09-0210-202/+114
| | | | | | | | | | | | | | | | | | | | | Summary: This patch follows the spirit of D63594, and removes some null checks for things which should be operating invariants. Specifically {Read,Write}[GF]PR now no longer check whether the supplied buffers are null, because they never are. After this, the Do*** versions of these function no longer serve any purpose and are inlined into their callers. Other cleanups are possible here too, but I am taking this one step at a time because this involves a lot of architecture-specific code, which I don't have the hardware to test on (I did do a build-test though). Reviewers: mgorny, jankratochvil, omjavaid, alexandreyy, uweigand Subscribers: nemanjai, javed.absar, kbarton, lldb-commits Differential Revision: https://reviews.llvm.org/D66744 llvm-svn: 370653
* [ARM64] Simplify RegisterInfos_arm64.h with macro based RegisterInfo arrayOmair Javaid2019-09-021-181/+258
| | | | | | | | | | This patches paves way for upcoming SVE RegisterInfo definitions. This is cosmetic change which allows us to define ARM64 RegisterInfo using macros. In future we ll have define two different RegisterInfos to choose between SVE vs non-SVE RegisterInfo with decision being made at thread creation. Differential Revision: https://reviews.llvm.org/D66934 llvm-svn: 370644
* [lldb][NFC] Move Clang-specific flags to ClangUserExpressionRaphael Isemann2019-08-301-0/+17
| | | | | | | | | LLVMUserExpression doesn't use these variables and they are all specific to Clang. Also removes m_const_object as this was actually never used by anyone (and Clang didn't report it as we assigned it in the constructor which seems to count as use). llvm-svn: 370440
* [lldb][NFC] Document options parameter in ClangUserExpression constructorRaphael Isemann2019-08-291-0/+3
| | | | | | Somehow this option was only documented in the swift branch. llvm-svn: 370395
* Revert "[TSanRuntime] Upstream thread swift race detector."Davide Italiano2019-08-292-35/+6
| | | | | | Sometimes it's easier to resolve merge conflict than arguing. llvm-svn: 370385
* Fix GetDIEForDeclContext so it only returns entries matching the provided ↵Pavel Labath2019-08-291-3/+4
| | | | | | | | | | | | context Currently, we return all the entries such that their decl_ctx pointer >= decl_ctx provided. Instead, we should return only the ones that decl_ctx pointer == decl_ctx provided. Differential Revision: https://reviews.llvm.org/D66357 Patch by Guilherme Andrade <guiandrade@google.com>. llvm-svn: 370374
* Remove DWARFExpression::LocationListSizePavel Labath2019-08-292-22/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The only reason for this function's existance is so that we could pass the correct size into the DWARFExpression constructor. However, there is no harm in passing the entire data extractor into the DWARFExpression, since the same code is performing the size determination as well as the subsequent parse. So, if we get malformed input or there's a bug in the parser, we'd compute the wrong size anyway. Additionally, reducing the number of entry points into the location list parsing machinery makes it easier to switch the llvm debug_loc(lists) parsers. While inside, I added a couple of tests for invalid location list handling. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D66789 llvm-svn: 370373
* [TSanRuntime] Upstream thread swift race detector.Davide Italiano2019-08-292-6/+35
| | | | | | | | | | | | | | | | | | | Summary: This is self-contained, and doesn't need anything in the compiler to work. Mainly to reduce the diff between upstream and downstream. Patch by Kuba Mracek! Reviewers: kubamracek Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66915 llvm-svn: 370286
* Update name of objc runtime SPI function we call for class names.Jason Molenda2019-08-281-1/+1
| | | | | | | | | | A new SPI was added to the objc runtime to get class names without any demangling; AppleObjCRuntimeV2::ParseClassInfoArray was using the original prototype name but had not been updated for the final name yet, so lldb was falling back to the old function and doing extra work for classes that were demangled. This commit fixes that. llvm-svn: 370152
* Revert "[lldb] Move redundant persistent variable counter to ↵Adrian Prantl2019-08-271-10/+0
| | | | | | | | | | | | ClangPersistentVariables" This reverts commit r367842 since it wasn't quite as NFC as advertised and broke Swift support. See https://reviews.llvm.org/D46083 for the rationale behind the original functionality. rdar://problem/54619322 llvm-svn: 370126
* [Platform/Android] Read the adb server from an env variable if setNathan Lanza2019-08-271-1/+6
| | | | | | | | | | | | | | | Summary: The environment variable ANDROID_ADB_SERVER_PORT can be defined to have adbd litsen on a different port. Teach lldb how to understand this via simply checking the env var. Reviewers: xiaobai, clayborg Subscribers: srhines Differential Revision: https://reviews.llvm.org/D66689 llvm-svn: 370106
* [lldb] Fix x86 compilationTatyana Krasnukha2019-08-276-21/+19
| | | | | | | | Differential Revision: https://reviews.llvm.org/D66655 Patch by Leonid Mashinskiy llvm-svn: 370078
* DWARFExpression: Simplify class interfacePavel Labath2019-08-276-35/+49
| | | | | | | | | | | | | | | | | Summary: The DWARFExpression methods have a lot of arguments. This removes two of them by removing the ability to slice the expression via two offset+size parameters. This is a functionality that it is not always needed, and when it is, we already have a different handy way of slicing a data extractor which we can use instead. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66745 llvm-svn: 370027
* [lldb][NFC] Remove dead code that handles situations where LLDB has no dummy ↵Raphael Isemann2019-08-261-10/+5
| | | | | | | | | | | | | | | | | | | | | | target Summary: We always have a dummy target, so any error handling regarding a missing dummy target is dead code now. Also makes the CommandObject methods that return Target& to express this fact in the API. This patch just for the CommandObject part of LLDB. I'll migrate the rest of LLDB in a follow-up patch that's WIP. Reviewers: labath Reviewed By: labath Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66737 llvm-svn: 369939
* Really fix the type mismatch error in GDBRemoteCommunicationServerCommonPavel Labath2019-08-261-2/+2
| | | | | | | | My previous attempt in attempt in r369904 actually broke the 32bit build because File::Read expects to take a reference to size_t. Fix the warning by using SIZE_MAX to denote failure instead. llvm-svn: 369910
* [ProcessWindows] Remove equivalent macrosTatyana Krasnukha2019-08-262-4/+4
| | | | llvm-svn: 369908
* Fix a type mismatch error in GDBRemoteCommunicationServerCommonPavel Labath2019-08-261-1/+1
| | | | | | | GetU64 returns a uint64_t. Don't store it in size_t as that is only 32-bit on 32-bit platforms. llvm-svn: 369904
* Postfix: move more code out of the PDB pluginPavel Labath2019-08-262-48/+14
| | | | | | | | | | | | | | | | Summary: Previously we moved the code which parses a single expression out of the PDB plugin, because that was useful for DWARF expressions in breakpad. However, FPO programs are used in breakpad files too (when unwinding on windows), so this completes the job, and moves the rest of the FPO parser too. Reviewers: amccarth, aleksandr.urakov Subscribers: aprantl, markmentovai, rnk, lldb-commits Differential Revision: https://reviews.llvm.org/D66634 llvm-svn: 369894
* Breakpad: Add support for parsing STACK WIN recordsPavel Labath2019-08-262-4/+119
| | | | | | | | | | | | Summary: The fields that aren't useful for us right now are simply ignored. Reviewers: amccarth, markmentovai Subscribers: rnk, lldb-commits Differential Revision: https://reviews.llvm.org/D66633 llvm-svn: 369892
* [NFC] Fix comments and formatting.Jonas Devlieghere2019-08-232-55/+60
| | | | llvm-svn: 369827
* Upstream support for macCatalyst Mach-O binaries.Adrian Prantl2019-08-232-144/+225
| | | | | | | | | | | | On macOS one Mach-O slice can contain multiple load commands: One load command for being loaded into a macOS process and one load command for being loaded into a macCatalyst process. This patch adds support for the new load command and makes sure ObjectFileMachO returns the Architecture that matches the Module. Differential Revision: https://reviews.llvm.org/D66626 llvm-svn: 369814
* Windows: explicitly cast constants to `DWORD`Saleem Abdulrasool2019-08-231-2/+2
| | | | | | | | | | STATUS_SINGLE_STEP and STATUS_BREAKPOINT are defined as 0x8------ which is negative and thus can't be implicitly narrowed to a DWORD which is unsigned. The value is defined differently across winnt.h and ntstatus.h. Patch by Gwen Mittertreiner! llvm-svn: 369788
* [Symbol] Decouple clang from DeclVendorAlex Langford2019-08-235-3/+48
| | | | | | | | | | Summary: This removes DeclVendor's dependency on clang (and ClangASTContext). DeclVendor has no need to know about specific TypeSystems. Differential Revision: https://reviews.llvm.org/D66628 llvm-svn: 369735
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-229-13/+29
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-229-29/+13
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-229-13/+29
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* Remove redundant curly braces.Adrian Prantl2019-08-221-2/+2
| | | | llvm-svn: 369670
* [lldb] Fix `TestDataFormatterStdList` regressionJan Kratochvil2019-08-221-7/+13
| | | | | | | | | | | | | | | | Since D66174 I see failures of TestDataFormatterStdList in about 50% of runs on Fedora 30 x86_64 libstdc++. I have found out that LLDB internally expects these RegularExpressions to be matched in their alphabetical order: ^std::(__cxx11::)?list<.+>(( )?&)?$ ^std::__[[:alnum:]]+::list<.+>(( )?&)?$ But since D66174 they are sometimes matched in reverse order. In fact it was only some luck it worked before as there is internally std::map<lldb::RegularExpressionSP, FormatterImpl> (FormattersContainer). Differential Revision: https://reviews.llvm.org/D66398 llvm-svn: 369655
* Add char8_t support (C++20)Jonas Devlieghere2019-08-213-0/+68
| | | | | | | | | | | | This patch adds support for the char8_t type introduced in C++20 char8_t. The original patch was submitted by James Blachly on the LLDB mailing list [1]. I modified the patch a bit and added a test. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html Differential revision: https://reviews.llvm.org/D66447 llvm-svn: 369582
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-2111-42/+33
| | | | | | | | | | | | | | | This patch generalizes the FindTypes with CompilerContext interface to support looking up a type of unknown kind by name, as well as looking up a type inside an unspecified submodule. These features are motivated by the Swift branch, but are fully tested via unit tests and lldb-test on llvm.org. Specifically, this patch adds an AnyModule and an AnyType CompilerContext kind. Differential Revision: https://reviews.llvm.org/D66507 rdar://problem/54471165 llvm-svn: 369555
* Recommit "Minidump/Windows: Fix module lookup""Pavel Labath2019-08-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This recommits r368416, which was reverted in r368838 because of test failures under ASAN. These have been dealt with by llvm r369370. The original commit message was: When opening a minidump, we were failing to find an executable because we were searching for i386-unknown-windows, whereas we recognize the pe/coff files as i386-pc-windows. This fixes the triple computation code in the minidump parser to match pe/coff, and adds an appropriate test. NB: I'm not sure setting the vendor to "pc" is really correct for arm(64) windows, but right now that seems to match what we do in the pe/coff case (ArchSpec.cpp:935). Reviewers: clayborg, amccarth Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D65955 llvm-svn: 369523
OpenPOWER on IntegriCloud