summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* Enhance SymbolFileDWARF::ParseDeclsForContext performancePavel Labath2019-09-244-19/+13
| | | | | | | | | | | | | | | | | | | This implements DWARFASTParserClang::EnsureAllDIEsInDeclContextHaveBeenParsed so as to provide a faster way to ensure all DIEs linked to a certain declaration context have been parsed. Currently, we rely on SymbolFileDWARF::ParseDeclsForContext calling DWARFASTParserClang::GetDIEForDeclContext, and only then DWARFASTParserClang::GetDeclForUIDFromDWARF. This change shortcuts that logic and removes redundant calls to DWARFASTParserClang:: GetClangDeclForDIE by deleting DIEs from the m_decl_ctx_to_die map once they have been parsed. Differential Revision: https://reviews.llvm.org/D67760 Patch by Guilherme Andrade <guiandrade@google.com>. llvm-svn: 372744
* [LLDB] Add tests for PECOFF arm architecture identificationMartin Storsjo2019-09-241-1/+1
| | | | | | | | | | | | | | | Add a test case for the change from SVN r372657, and for the preexisting ARM identification. Add a missing ArchDefinitionEntry for PECOFF/arm64, and tweak the ArmNt case to set the architecture to armv7 (ArmNt never ran on anything lower than that). (This avoids a case where ArchSpec::MergeFrom would override the arch from arm to armv7 and ArchSpec::CoreUpdated would reset the OS to unknown at the same time.) Differential Revision: https://reviews.llvm.org/D67951 llvm-svn: 372741
* [LLDB] Fix typo in RegisterContextDarwin_arm64Martin Storsjo2019-09-241-1/+1
| | | | | | | | | In these cases, the register number should be calculated from fpu_d0, not fpu_s0. Differential Revision: https://reviews.llvm.org/D67892 llvm-svn: 372738
* [lldb] Use convert_to_slash in CppModuleConfigurationRaphael Isemann2019-09-241-3/+3
| | | | | | That's what we actually want to do. Might fix the Windows bot. llvm-svn: 372729
* [lldb][NFC] Use llvm::StringRef in formatters::NSStringSummaryProviderRaphael Isemann2019-09-241-11/+11
| | | | llvm-svn: 372724
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-2412-76/+252
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
* [LLDB] [Windows] Add missing ifdefs to fix building for non-x86 architecturesMartin Storsjo2019-09-241-1/+14
| | | | | | | | | | While debugging on those architectures might not be supported yet, the generic code should still be buildable. This file accesses x86 specific fields in the CONTEXT struct. Differential Revision: https://reviews.llvm.org/D67911 llvm-svn: 372699
* Ignore generated @import statements in the expression evaluatorRaphael Isemann2019-09-243-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ClangModulesDeclVendor is currently interpreting all injected `@import` statements in our expression wrapper as modules that the user has explicitly requested to be persistently loaded. As we inject `@import` statements with our std module prototype, the ClangModulesDeclVendor will start compiling and loading unrelated C++ modules because it thinks the user has requested that it should load them. As the ClangModulesDeclVendor is lacking the setup to compile these modules (e.g. it lacks the include paths), it will then actually just fail to compile them and cause the whole expression evaluation to fail. This causes these tests to fail on systems that enable the ClangModulesDeclVendor (such as macOS). This patch fixes this by preventing the ClangModulesDeclVendor from interpreting `@import` statements in the wrapper source code. This is done by check if the import happens in the fake source file containing our wrapper code (which implies it was generated by LLDB). This patch doesn't reenable the tests as there is more work needed to get the tests running on macOS (D67760) Reviewers: aprantl, shafik, jingham Subscribers: lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D61565 llvm-svn: 372690
* [LLDB] [PECOFF] Recognize arm64 executablesMartin Storsjo2019-09-231-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D67912 llvm-svn: 372657
* File::SetDescriptor() should require optionsJonas Devlieghere2019-09-234-9/+14
| | | | | | | | | | | | | | | | | | | | | | lvm_private::File::GetStream() can fail if m_options == 0 It's not clear from the header a File created with a descriptor will be not be usable by many parts of LLDB unless SetOptions is also called, but it is. This is because those parts of LLDB rely on GetStream() to use the file, and that in turn relies on calling fdopen on the descriptor. When calling fdopen, GetStream relies on m_options to determine the access mode. If m_options has never been set, GetStream() will fail. This patch adds options as a required argument to File::SetDescriptor and the corresponding constructor. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67792 llvm-svn: 372652
* [ABISysV] Fix regression for Simulator and MacABIJonas Devlieghere2019-09-231-7/+23
| | | | | | | | | | | | | | | The ABISysV ABI was refactored in r364216 to support the Windows ABI for x86_64. In particular it changed ABISysV_x86_64::CreateInstance to switch on the OS type. This breaks debugging MacABI apps as well as apps in the simulator. This adds back the necessary cases. We have a test on Github that exercises this code path and which I'd like to upstream once the remaining MacABI parts become available in clang. Differential revision: https://reviews.llvm.org/D67869 llvm-svn: 372642
* [LLDB] Add a missing specification of linking against dbghelpMartin Storsjo2019-09-231-0/+8
| | | | | | | | | | | | | | | | | | | The PECOFF object file plugin uses the dbghelp API, but doesn't specify that it has to be linked in anywhere. Current MSVC based builds have probably succeeded, as other parts in LLDB have had a "#pragma comment(lib, "dbghelp.lib")", but there's currently no such pragma in the PECOFF plugin. The "#pragma comment(lib, ...)" approach doesn't work in MinGW mode (unless the compiler is given the -fms-extensions option, and even then, it's only supported by clang/lld, not by GCC/binutils), thus add it to be linked via CMake. (The other parts of LLDB that use dbghelp are within _MSC_VER ifdefs.) Differential Revision: https://reviews.llvm.org/D67885 llvm-svn: 372587
* [lldb] Fix that importing decls in a TagDecl end up in wrong declaration ↵Raphael Isemann2019-09-231-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context (partly reverts D61333) Summary: In D61333 we dropped some code from ClangASTSource that checks if imported declarations ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit by the test suite but we didn't have any checks that were affected) and the code seems pointless (as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map). This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests which is currently the most reliable way to test this problem (it's a tricky setup, see description below). Fixes rdar://55502701 and rdar://55129537 -------------------------------------- Some more explanation what is actually going on and what is going wrong: The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map (even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no members. However, `frame var m` works just fine (and fixes all following `expr m` calls). The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST). When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen. This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import the `first` and `second` members as we don't need them for anything). After the expression is done, we take the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members. We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However, P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST). So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first `std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations and just print an empty map as a fallback. The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes the formatters happy as they can now see the members in the DeclContext they are querying. Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this. Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can tell), but that might have unintended side-effects and not sure what's the best way to implement this. Reviewers: friss, martong Reviewed By: martong Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik Tags: #lldb Differential Revision: https://reviews.llvm.org/D67803 llvm-svn: 372549
* [LLDB] Use SetErrorStringWithFormatv for cases that use LLVM style format ↵Martin Storsjo2019-09-212-6/+6
| | | | | | | | | | | strings SetErrorStringWithFormat only supports normal printf style format strings. Differential Revision: https://reviews.llvm.org/D67862 llvm-svn: 372485
* [LLDB] Use LLVM_FALLTHROUGH instead of a custom commentMartin Storsjo2019-09-211-1/+1
| | | | | | | | This fixes a warning when built with Clang in MinGW mode. Differential Revision: https://reviews.llvm.org/D67860 llvm-svn: 372484
* [LLDB] Check for the GCC/MinGW compatible arch defines for windows, in ↵Martin Storsjo2019-09-212-5/+5
| | | | | | | | | | | addition to MSVC defines This matches how it is done in all other similar ifdefs throughout lldb. Differential Revision: https://reviews.llvm.org/D67858 llvm-svn: 372483
* [LLDB] Fix compilation for MinGW, remove redundant class name on inline memberMartin Storsjo2019-09-211-1/+1
| | | | | | | | | | | | This fixes build errors like these: NativeRegisterContextWindows.h:22:33: error: extra qualification on member 'NativeRegisterContextWindows' NativeRegisterContextWindows::NativeRegisterContextWindows( ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ Differential Revision: https://reviews.llvm.org/D67856 llvm-svn: 372482
* [lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBERMichal Gorny2019-09-191-3/+4
| | | | | | | | Correct more uses of 0 instead of LLDB_INVALID_SIGNAL_NUMBER. Differential Revision: https://reviews.llvm.org/D67727 llvm-svn: 372300
* [lldb] Print better diagnostics for user expressions and modulesRaphael Isemann2019-09-188-68/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions. For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong: ``` (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) error: invalid operands to binary expression ('int' and 'double') ``` This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this: ``` (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float') printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) ~~~~~~^~~~ ``` To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to our internal wrapper code we inject. Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function) will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible. We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message without any context (and the original diagnostic in the user expression should be enough to explain the issue). Fixes rdar://24306342 Reviewers: JDevlieghere, aprantl, shafik, #lldb Reviewed By: JDevlieghere, #lldb Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65646 llvm-svn: 372203
* [ScriptInterpreter] Limit LLDB's globals to interactive mode.Jonas Devlieghere2019-09-181-6/+10
| | | | | | | | | | | Jim pointed out that the LLDB global variables should only be available in interactive mode. When used from a command for example, their values might be stale or not at all what the user expects. Therefore we want to explicitly make these variables unavailable. Differential revision: https://reviews.llvm.org/D67685 llvm-svn: 372192
* [ScriptInterpreter] Remove ScriptInterpreterPythonImpl::Clear() (NFC)Jonas Devlieghere2019-09-182-14/+0
| | | | | | This method is never called. llvm-svn: 372190
* [lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action listMichal Gorny2019-09-171-2/+3
| | | | | | | | | | Fix processing of "C" packet with signal for the whole process to default signal value for action list to LLDB_INVALID_SIGNAL_NUMBER rather than 0. Differential Revision: https://reviews.llvm.org/D67625 llvm-svn: 372090
* Reland "[lldb][NFC] Make ApplyObjcCastHack less scary"Raphael Isemann2019-09-171-9/+5
| | | | | | First version had a typo. llvm-svn: 372077
* [ScriptInterpreter] Initialize globals when loading a scripting module.Jonas Devlieghere2019-09-171-6/+6
| | | | | | | | | | | | | The LoadScriptingModule used by command script import wasn't initializing the LLDB global variables (things like `lldb.frame` and `lldb.debugger`). They would get initialized however when running the interactive script interpreter or running a single script line (e.g. `script print(lldb.frame)`). This patch fixes that by properly initializing the globals when loading a Python module. Differential revision: https://reviews.llvm.org/D67644 llvm-svn: 372060
* Revert "[lldb][NFC] Make ApplyObjcCastHack less scary"Jim Ingham2019-09-171-5/+9
| | | | | | | | | | | | | | This reverts commit 21641a2f6dbac22653befd03496e0850537882ff. It was causing the following test failures: lldb-Suite.lang/objc/objc-class-method.TestObjCClassMethod.py lldb-Suite.lang/objc/foundation.TestObjCMethodsString.py lldb-Suite.lang/objc/foundation.TestConstStrings.py lldb-Suite.lang/objc/radar-9691614.TestObjCMethodReturningBOOL.py lldb-Suite.lang/objc/foundation.TestObjCMethodsNSArray.py llvm-svn: 372057
* [NFC] Move dumping into GDBRemotePacketJonas Devlieghere2019-09-161-5/+2
| | | | | | | | This moves the dumping logic from the GDBRemoteCommunicationHistory class into the GDBRemotePacket so that it can be reused from the reproducer command object. llvm-svn: 372028
* [lldb][NFC] Make ApplyObjcCastHack less scaryRaphael Isemann2019-09-161-9/+5
| | | | llvm-svn: 372017
* [Reproducer] Move GDB Remote Packet into Utility. (NFC)Jonas Devlieghere2019-09-1310-153/+34
| | | | | | | | | | | | | | To support dumping the reproducer's GDB remote packets, we need the (de)serialization logic to live in Utility rather than the GDB remote plugin. This patch renames StreamGDBRemote to GDBRemote and moves the relevant packet code there. Its uses in the GDBRemoteCommunicationHistory and the GDBRemoteCommunicationReplayServer are updated as well. Differential revision: https://reviews.llvm.org/D67523 llvm-svn: 371907
* [lldb][NFC] Remove ArgEntry::ref memberRaphael Isemann2019-09-131-4/+4
| | | | | | | | | | | The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
* [Target] Move InferiorCall to ProcessAlex Langford2019-09-132-64/+0
| | | | | | | | | | | | | | | | | | | Summary: InferiorCall is only ever used in Process, and it is not specific to POSIX. By moving it to Process, we can remove all dependencies on plugins from Process. Moving InferiorCall to Process seems to achieve this quite well. Additionally, the name InferiorCall is a little vague now, so we rename it something a bit more specific. Reviewers: JDevlieghere, clayborg, compnerd, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67472 llvm-svn: 371796
* [Reproducer] Move GDB Remote Provider into Reproducer (NFC)Jonas Devlieghere2019-09-111-42/+4
| | | | | | | | | | | | | | Originally the idea was for providers to be defined close to where they are used. While this helped designing the providers in such a way that they don't depend on each other, it also means that it's not possible to access them from a central place. This proved to be a problem for some providers and resulted in them living in the reproducer class. The ProcessGDBRemote provider is the last remaining exception. This patch makes things consistent and moves it into the reproducer like the other providers. llvm-svn: 371685
* [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
OpenPOWER on IntegriCloud