summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* Update SymbolFilePDB for FindTypes API change.Adrian Prantl2019-10-012-22/+17
| | | | | | This is untested, I don't have access to a Windows machine. llvm-svn: 373342
* [lldb][NFC] Disallow changing the ASTContext of an ClangASTContext after ↵Raphael Isemann2019-10-012-6/+2
| | | | | | | | | | | construction. We have no use case in LLDB where we actually do want to change the ASTContext after it the ClangASTContext has been constructed. All callers of setASTContext are just setting the ASTContext directly after construction, so we might as well make this a Constructor instead of supporting this tricky use case. llvm-svn: 373330
* [clang][lldb][NFC] Encapsulate ExternalASTMerger::ImporterSourceRaphael Isemann2019-10-014-11/+11
| | | | | | NFC preparation work for upcoming ExternalASTMerger patches. llvm-svn: 373312
* [Windows] Added support of watchpoints to `NativeProcessWindows`Aleksandr Urakov2019-10-018-64/+835
| | | | | | | | | | | | | | | | Summary: This patch adds support of watchpoints to the new `NativeProcessWindows` plugin. The same tests as in D67168 pass with these changes when the old plugin is turned off, so they will cover this functionality when the old plugin is gone. Reviewers: asmith, amccarth, stella.stamenova, labath Reviewed By: labath Subscribers: labath, jfb, JDevlieghere, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D67222 llvm-svn: 373300
* Remove unused "append" parameter from FindTypes APIAdrian Prantl2019-09-3011-104/+69
| | | | | | | | | | | | | I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it incorrectly (passing append=false in a for-loop to recursive calls to FindTypes would yield only the very last set of results), but instead of fixing it, removing it seemed like an even better option. rdar://problem/54412692 Differential Revision: https://reviews.llvm.org/D68171 llvm-svn: 373224
* Use llvm for dumping DWARF expressionsPavel Labath2019-09-301-1/+0
| | | | | | | | | | | | | | | Summary: It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo structs (which is what is needed to turn dwarf register numbers into strings). Reviewers: JDevlieghere, aprantl, jasonmolenda Subscribers: tatyana-krasnukha, lldb-commits Differential Revision: https://reviews.llvm.org/D67966 llvm-svn: 373208
* [lldb][NFC][modern-type-lookup] Remove while(false) behind if() {}Raphael Isemann2019-09-301-2/+0
| | | | | | | | This was originally a 'do { ... } while (false);' like in the rest of the function, but the do was refactored into an 'if' without also removing the trailing 'while(false);' llvm-svn: 373206
* Give an error when StepUsingScriptedThreadPlan is passed a bad classname.Jim Ingham2019-09-282-5/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D68173 llvm-svn: 373135
* remove File::SetStream(), make new files instead.Lawrence D'Anna2019-09-278-91/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes File::SetStream() and File::SetDescriptor(), and replaces most direct uses of File with pointers to File. Instead of calling SetStream() on a file, we make a new file and replace it. My ultimate goal here is to introduce a new API class SBFile, which has full support for python io.IOStream file objects. These can redirect read() and write() to python code, so lldb::Files will need a way to dispatch those methods. Additionally it will need some form of sharing and assigning files, as a SBFile will be passed in and assigned to the main IO streams of the debugger. In my prototype patch queue, I make File itself copyable and add a secondary class FileOps to manage the sharing and dispatch. In that case SBFile was a unique_ptr<File>. (here: https://github.com/smoofra/llvm-project/tree/files) However in review, Pavel Labath suggested that it be shared_ptr instead. (here: https://reviews.llvm.org/D67793) In order for SBFile to use shared_ptr<File>, everything else should as well. If this patch is accepted, I will make SBFile use a shared_ptr I will remove FileOps from future patches and use subclasses of File instead. Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67891 llvm-svn: 373090
* Unwind: Add a stack scanning mechanism to support win32 unwindingPavel Labath2019-09-274-5/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Windows unwinding is weird. The unwind rules do not (always) describe the precise layout of the stack, but rather expect the debugger to scan the stack for something which looks like a plausible return address, and the unwind based on that. The reason this works somewhat reliably is because the the unwinder also has access to the frame sizes of the functions on the stack. This allows it (in most cases) to skip function pointers in local variables or function arguments, which could otherwise be mistaken for return addresses. Implementing this kind of unwind mechanism in lldb was a bit challenging because we expect to be able to statically describe (in the UnwindPlan) structure, the layout of the stack for any given instruction. Giving a precise desription of this is not possible, because it requires correlating information from two functions -- the pushed arguments to a function are considered a part of the callers stack frame, and their size needs to be considered when unwinding the caller, but they are only present in the unwind entry of the callee. The callee may end up being in a completely different module, or it may not even be possible to determine it statically (indirect calls). This patch implements this functionality by introducing a couple of new APIs: SymbolFile::GetParameterStackSize - return the amount of stack space taken up by parameters of this function. SymbolFile::GetOwnFrameSize - the size of this function's frame. This excludes the parameters, but includes stuff like local variables and spilled registers. These functions are then used by the unwinder to compute the estimated location of the return address. This address is not always exact, because the stack may contain some additional values -- for instance, if we're getting ready to call a function then the stack will also contain partially set up arguments, but we will not know their size because we haven't called the function yet. For this reason the unwinder will crawl up the stack from the return address position, and look for something that looks like a possible return address. Currently, we assume that something is a valid return address if it ends up pointing to an executable section. All of this logic kicks in when the UnwindPlan sets the value of CFA as "isHeuristicallyDetected", which is also the final new API here. Right now, only SymbolFileBreakpad implements these APIs, but in the future SymbolFilePDB will use them too. Differential Revision: https://reviews.llvm.org/D66638 llvm-svn: 373072
* Convert FileSystem::Open() to return Expected<FileUP>Lawrence D'Anna2019-09-268-65/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
* [lldb][modern-type-lookup] Fix crash when activating modern-type-lookup on LinuxRaphael Isemann2019-09-261-2/+1
| | | | | | | There is no ClangModulesDeclVendor on Linux so that cast is triggering an assert. Let's just remove it as it just casts the type to itself. llvm-svn: 372974
* [Dwarf] Fix switch cases that take an dw_tag_t.Jonas Devlieghere2019-09-253-0/+10
| | | | | | Now that dw_tag_t is an enum, a default case is required. llvm-svn: 372920
* [Dwarf] Make dw_tag_t a typedef for llvm::dwarf::Tag instead of uint16_t.Jonas Devlieghere2019-09-256-10/+12
| | | | | | | | | | | | Currently dw_tag_t is a typedef for uint16_t. This patch changes makes dw_tag_t a typedef for llvm::dwarf::Tag. This enables us to use the full power of the DWARF utilities in LLVM without having to do the cast every time. With this approach, we only have to do the cast when reading the ULEB value. Differential revision: https://reviews.llvm.org/D68005 llvm-svn: 372891
* Have ABI plugins vend llvm MCRegisterInfo dataPavel Labath2019-09-2529-43/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I was recently surprised to learn that there is a total of 2 (two) users of the register info definitions contained in the ABI plugins. Yet, the defitions themselves span nearly 10kLOC. The two users are: - dwarf expression pretty printer - the mechanism for augmenting the register info definitions obtained over gdb-remote protocol (AugmentRegisterInfoViaABI) Both of these uses need the DWARF an EH register numbers, which is information that is already available in LLVM. This patch makes it possible to do so. It adds a GetMCRegisterInfo method to the ABI class, which every class is expected to implement. Normally, it should be sufficient to obtain the definitions from the appropriate llvm::Target object (for which I provide a utility function), but the subclasses are free to construct it in any way they deem fit. We should be able to always get the MCRegisterInfo object from llvm, with one important exception: if the relevant llvm target was disabled at compile time. To handle this, I add a mechanism to disable the compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD cmake setting. This ensures all our existing are able to create their MCRegisterInfo objects. The new MCRegisterInfo api is not used yet, but the intention is to make use of it in follow-up patches. Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits Differential Revision: https://reviews.llvm.org/D67965 llvm-svn: 372862
* [lldb] Fix undefined behavior when having fixits in undefined top level exprsRaphael Isemann2019-09-251-1/+4
| | | | | | | | In top level expressions, we don't have a m_source_code and we don't need to change the source bounds (as no wrapping happend there). Fixes the test on the sanitizer bot. llvm-svn: 372817
* remove unused method ResetOutputFileHandle()Jonas Devlieghere2019-09-252-4/+0
| | | | | | | | | | | ResetOutputFileHandle() isn't being used by anything. Also it's using FILE*, which is something we should be doing less of. Remove it. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D68001 llvm-svn: 372800
* [NFC] Fix typo in the "kind" description for the software single-step breakpointTatyana Krasnukha2019-09-241-1/+1
| | | | llvm-svn: 372763
* [lldb] [Process/NetBSD] Fix handling LLDB_INVALID_SIGNAL_NUMBERMichal Gorny2019-09-241-2/+4
| | | | | | | | | Fix NativeProcessNetBSD::Resume() to handle LLDB_INVALID_SIGNAL_NUMBER correctly. Fixes breakage caused by r372090 and r372300. I have major rewrite of that function pending; however, the fixes to gdb-remote were committed prior to that. llvm-svn: 372755
* 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
OpenPOWER on IntegriCloud