summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-192-19/+229
| | | | | | | | | | | | | | | | | | | | | | | | without any arguments, i.e. 'int main()' and add support to test it Summary: - Fix a null array access bug. This happens when creating the lldb type for a function that has no argument. - Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target. - Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin - The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type. - Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue. - Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's. - There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown. - There is no information about scoped enumeration. The compiler type is represented as an unscoped one. Reviewers: zturner, lldb-commits, davide, asmith Reviewed By: zturner, asmith Subscribers: llvm-commits, davide Differential Revision: https://reviews.llvm.org/D41427 llvm-svn: 322995
* Fix assertion in ObjectFileELFPavel Labath2018-01-171-0/+2
| | | | | | | | | | In D40616 I (mistakenly) assumed that logging an llvm::Error would clear it. This of course is only true if logging is actually enabled. This fixes the assertion by manually clearing the error, but it raises the point of whether we need a special error-clearing logging primitive. llvm-svn: 322664
* One more attempt to fix NetBSD buildPavel Labath2018-01-151-1/+1
| | | | llvm-svn: 322477
* Fix NetBSD build for llvm r322475Pavel Labath2018-01-151-3/+3
| | | | llvm-svn: 322476
* [lldb] Add support to cache a PDB's global scope and fix a bug in getting ↵Aaron Smith2018-01-133-72/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the source file name for a compiland Summary: This commit is a combination of the following changes: - Cache PDB's global scope (executable) in SymbolFilePDB - Change naming of `cu` to `compiland` which is PDB specific - Change ParseCompileUnitForSymIndex to ParseCompileUnitForUID. Prefer using a common name `UID` instead of PDB's `System Index` Adding one more argument `index` to this method, which is used to specify the index of the compile unit in a cached compile unit array - Add GetPDBCompilandByUID method to simply code - Fix a bug in getting the source file name for a PDB compiland. For some reason, PDBSymbolCompiland::getSourceFileName() could return an empty name, so if that is true, we have to walk through all source files of this compiland and determine the right source file used to generate this compiland based on language indicated. The previous implementation called PDBSession::findOneSourceFile method to get its name for the compiland. This is not accurate since the `one source file` found could be a header other than source file. Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41428 llvm-svn: 322433
* We have two sources for path remapping information that we get outJason Molenda2018-01-121-15/+18
| | | | | | | | | | | | | | | | | of a dSYM per-uuid plist that may be present (dsymutil does not create this plist, it is only added after the fact by additional tools) -- either the DBGBuildSourcePath + DBGSourcePath pair of k-v entries which give us the build-time and debug-time remapping, or the newer DBGSourcePathRemapping dictionary which may give us multiple remappings. I'm changing the order that we process these & add them to the list of source remappings. If the DBGSourcePathRemapping dict is present, it should be the first entries we will try. <rdar://problem/36481989> llvm-svn: 322418
* When parsing the target.xml register file, if no architecture hasJason Molenda2018-01-121-0/+13
| | | | | | | | | | | | | | | | | been specified yet (either by the user, or by one of the lldb extensions like qHostInfo or qProcessInfo), and the target.xml includes a <architecture> tag specifying x86_64, set the architecture appropriately. I'm not sure what we can expect to see in the <architecture> tag, so I'm only doing this for x86_64 right now where I've seen "i386:x86_64" used. I've seen a target.xml from a jtag board that sends just "arm" because it doesn't know more specifically what type of board it is connected to... <rdar://problem/29908970> llvm-svn: 322339
* Check existence of each required component during construction of ↵Tatyana Krasnukha2018-01-112-166/+174
| | | | | | | | | | | | | | | | | | | | | | | LLVMCDisassembler. Summary: Actually, fix two issues: # remove repeat creation of reg_info, use m_reg_info_ap for createMCAsmInfo instead; # remove possibility to dereference nullptr during createMCAsmInfo invocation, that could lead to undefined behavior. Placed checking of a component right after its creation to simplify the code and avoid same issues later. Reviewers: zturner, clayborg, jingham, jasonmolenda, labath Reviewed By: clayborg, labath Subscribers: labath, lldb-commits Differential Revision: https://reviews.llvm.org/D41584 llvm-svn: 322270
* Advanced guessing of rendezvous breakpoint (resubmit)Eugene Zemtsov2018-01-112-67/+132
| | | | | | | | | | | | | When rendezvous structure is not initialized we need to set up rendezvous breakpoint anyway. In this case the code will locate dynamic loader (interpreter) and look for known function names. This is r322209, but with fixed VDSO loading fixed. Bug: https://bugs.llvm.org/show_bug.cgi?id=25806 Differential Revision: https://reviews.llvm.org/D41533 llvm-svn: 322251
* Revert "Advanced guessing of rendezvous breakpoint"Eugene Zemtsov2018-01-102-126/+42
| | | | | | | This reverts commit r322209, because it broke TestNoreturnUnwind,TestInferiorAssert and TestNumThreads on i386. llvm-svn: 322229
* Advanced guessing of rendezvous breakpointEugene Zemtsov2018-01-102-42/+126
| | | | | | | | | | | When rendezvous structure is not initialized we need to set up rendezvous breakpoint anyway. In this case the code will locate dynamic loader (interpreter) and look for known function names. Bug: https://bugs.llvm.org/show_bug.cgi?id=25806 Differential Revision: https://reviews.llvm.org/D41533 llvm-svn: 322209
* Handle O reply packets during qRcmdPavel Labath2018-01-105-3/+55
| | | | | | | | | | | | | | | | | | | | Summary: Gdb servers like openocd may send many $O reply packets for the client to output during a qRcmd command sequence. Currently, lldb interprets the first O packet as an unexpected response. Besides generating no output, this causes lldb to get out of sync with future commands because it continues reading O packets from the first command as response to subsequent commands. This patch handles any O packets during an qRcmd, treating the first non-O packet as the true response. Preliminary discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013078.html Reviewers: clayborg Reviewed By: clayborg Subscribers: labath, lldb-commits Differential Revision: https://reviews.llvm.org/D41745 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 322190
* Another attempt to fix FreeBsd buildPavel Labath2018-01-103-18/+13
| | | | | | | | | | the previous fix did not work because of different const qualifications on the envp pointer. This should resolve that (and remove a couple of const_casts in the process). llvm-svn: 322187
* Fix windows and freebsd builds for r322174 (Environment)Pavel Labath2018-01-101-3/+2
| | | | llvm-svn: 322176
* Add Utility/Environment class for handling... environmentsPavel Labath2018-01-1013-98/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was some confusion in the code about how to represent process environment. Most of the code (ab)used the Args class for this purpose, but some of it used a more basic StringList class instead. In either case, the fact that the underlying abstraction did not provide primitive operations for the typical environment operations meant that even a simple operation like checking for an environment variable value was several lines of code. This patch adds a separate Environment class, which is essentialy a llvm::StringMap<std::string> in disguise. To standard StringMap functionality, it adds a couple of new functions, which are specific to the environment use case: - (most important) envp conversion for passing into execve() and likes. Instead of trying to maintain a constantly up-to-date envp view, it provides a function which creates a envp view on demand, with the expectation that this will be called as the very last thing before handing the value to the system function. - insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value) pair and inserts it into the environment map. - compose(value_type KeyValue) - takes a map entry and converts in back into "KEY=VALUE" representation. With this interface most of the environment-manipulating code becomes one-liners. The only tricky part was maintaining compatibility in SBLaunchInfo, which expects that the environment entries are accessible by index and that the returned const char* is backed by the launch info object (random access into maps is hard and the map stores the entry in a deconstructed form, so we cannot just return a .c_str() value). To solve this, I have the SBLaunchInfo convert the environment into the "envp" form, and use it to answer the environment queries. Extra code is added to make sure the envp version is always in sync. (This also improves the layering situation as Args was in the Interpreter module whereas Environment is in Utility.) Reviewers: zturner, davide, jingham, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41359 llvm-svn: 322174
* Look for external types in all clang modules imported by the current symbol ↵Adrian Prantl2018-01-043-51/+86
| | | | | | | | | | | | | file. This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle that was particularly noticable when debugging LLVM itself. Debugging without clang modules and DWO handling should be unaffected by this patch. <rdar://problem/32436209> llvm-svn: 321802
* [MacOSX-Kernel] Remove broken KDP_IMAGEPATH support.Davide Italiano2018-01-021-37/+0
| | | | llvm-svn: 321652
* [ARM64] Remove unused function. NFCI.Davide Italiano2018-01-021-13/+0
| | | | llvm-svn: 321651
* Remove duplicate declaration from D41550; NFC Aaron Smith2017-12-281-4/+0
| | | | llvm-svn: 321514
* Update failing PDB unit tests that are searching for symbols by regexAaron Smith2017-12-281-0/+4
| | | | | | | | | | | | Summary: D41086 fixed an exception in FindTypes()/FindTypesByRegex() and caused two lldb unit test to fail. This change updates the unit tests to pass again. Reviewers: zturner, lldb-commits, labath, clayborg, asmith Reviewed By: asmith Differential Revision: https://reviews.llvm.org/D41550 llvm-svn: 321511
* [lldb] Stop searching for a symbol in a pdb by regexAaron Smith2017-12-223-15/+17
| | | | | | | | | | | | | | | | | Summary: It was possible when searching for a symbol by regex in a pdb that an invalid regex would cause an exception on Windows. This updates the code to avoid throwing an exception. When fixing the exception it was decided there is no reason to search for a symbol in a pdb by regex. To support this, SymbolFilePDB::FindTypes() now only searches for types by name and no longer calls FindTypesByRegEx(). Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: clayborg Differential Revision: https://reviews.llvm.org/D41086 llvm-svn: 321344
* Change the default Aarch64 ISA to be v8.2 to correctly decode newerJason Molenda2017-12-221-0/+5
| | | | | | | instructions (e.g. on the new iphones). <rdar://problem/30585124> llvm-svn: 321328
* Enable more abilities in SymbolFilePDBAaron Smith2017-12-221-2/+45
| | | | | | | | | | | | | | | | Summary: 1) Finding symbols through --symfile 2) More abilities: Functions, Blocks, GlobalVariables, LocalVariables, VariableTypes Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: clayborg Differential Revision: https://reviews.llvm.org/D41092 llvm-svn: 321327
* Bring clang options in error messages up to date.Adrian Prantl2017-12-211-4/+4
| | | | llvm-svn: 321322
* Make sure DataBufferLLVM contents are writablePavel Labath2017-12-214-46/+24
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We sometimes need to write to the object file we've mapped into memory, generally to apply relocations to debug info sections. We've had that ability before, but with the introduction of DataBufferLLVM, we have lost it, as the underlying llvm class (MemoryBuffer) only supports read-only mappings. This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer class as a back-end, as this one guarantees to return a writable buffer. This removes the need for the "Private" flag to the DataBufferLLVM creation functions, as it was really used to mean "writable". The LLVM function also does not have the NullTerminate flag, so I've modified our clients to not require this feature and removed that flag as well. Reviewers: zturner, clayborg, jingham Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits Differential Revision: https://reviews.llvm.org/D40079 llvm-svn: 321255
* Fix a couple of warnings (NFC)Adrian Prantl2017-12-192-1/+2
| | | | llvm-svn: 321120
* Fix regression in jModulesInfo packet handlingPavel Labath2017-12-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | The recent UUID cleanups exposed a bug in the parsing code for the jModulesInfo response, which was passing wrong value for the second argument to UUID::SetFromStringRef (it passed the length of the string, whereas the correct value should be the number of decoded bytes we expect to receive). This was not picked up by tests, because they test with 16-byte uuids, for which the function happens to do the right thing even if the length does not match (if the length does not match, the function does not update m_num_uuid_bytes member, but that member is already 16 to begin with). I fix that and add a test with 20-byte uuid to catch if this regresses. I have also added more safeguards into the parsing code to fail if we cannot parse the entire uuid field we recieve. While testing the latter part, I noticed that the "negative" jModulesInfo tests were succeeding because we were sending malformed json (and not because the json contents was invalid), so I make those tests a bit more robuts as well. llvm-svn: 320985
* llgs: Propagate the environment when launching the inferior from command linePavel Labath2017-12-182-41/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were failing to propagate the environment when lldb-server was started with a pre-loaded process (e.g.: lldb-server gdbserver -- inferior --inferior_args) This patch makes sure the environment is propagated. Instead of adding a new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to complement SetLaunchArgs and SetLaunchFlags, I replace these with a more generic SetLaunchInfo, which can be used to set any launch-related property. The accompanying test also verifies that the server correctly terminates the connection after sending the exit packet (specifically, that it does not send the exit packet twice). Reviewers: clayborg, eugene Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41070 llvm-svn: 320984
* Fix FreeBSD build broken by r320966Pavel Labath2017-12-181-25/+22
| | | | llvm-svn: 320969
* Add LLVMObject dependency to our ObjectFileELF pluginPavel Labath2017-12-181-0/+1
| | | | llvm-svn: 320967
* Reduce x86 register context boilerplate.Pavel Labath2017-12-185-82/+71
| | | | | | | | | | | | | | | | | | | | | | Summary: The x86 FPR struct was defined as a struct containing a union between two members: XSAVE and FXSAVE. This patch makes FPR a union directly to remove one layer of indirection when trying to access the members. The initial layout of these two structs is identical, which is recognised by the fact that XSAVE has FXSAVE as its first member, so we also considered removing one more layer and leave FPR identical to XSAVE struct, but stopped short of doing that, as the FPR may be used to store different layouts in the future (e.g., ones generated by the FSAVE instruction). Reviewers: clayborg, krytarowski Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D41245 llvm-svn: 320966
* NPL: Clean up handling of inferior exitPavel Labath2017-12-182-47/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lldb-server was sending the "exit" packet (W??) twice. This happened because it was handling both the pre-exit (PTRACE_EVENT_EXIT) and post-exit (WIFEXITED) as exit events. We had some code which was trying to detect when we've already sent the exit packet, but this stopped working quite a while ago. This never really caused any problems in practice because the client automatically closes the connection after receiving the first packet, so the only effect of this was some warning messages about extra packets from the lldb-server test suite, which were ignored because they didn't fail the test. The new test suite will be stricter about this, so I fix this issue ignoring the first event. I think this is the correct behavior, as the inferior is not really dead at that point, so it's premature to send the exit packet. There isn't an actual test yet which would verify the exit behavior, but in my next patch I will add a test which will also test this functionality. Reviewers: eugene Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D41069 llvm-svn: 320961
* Fix 32-bit builds broken by 320813Pavel Labath2017-12-151-2/+2
| | | | | | cast to size_t to avoid narrowing error. llvm-svn: 320816
* ObjectFileELF: Add support for compressed sectionsPavel Labath2017-12-152-0/+62
| | | | | | | | | | | | | | | | Summary: We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables us to read data from debug info sections, which are sometimes compressed, particuarly in the split-dwarf case. This functionality is only available if llvm is compiled with zlib support. Reviewers: clayborg, zturner Subscribers: emaste, mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D40616 llvm-svn: 320813
* [ExpressionParser] Fix evaluation failures due to mismatch in C++ versions.Davide Italiano2017-12-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Clang recently switched to C++14 (with GNU extensions) as the default dialect, but LLDB didn't catch up. This causes failures as LLDB still evaluates ObjectiveC expressions as Objective C++ using C++98 as standard. There are things not available in C++98, including, e.g. nullptr. In some cases Objective-C `nil` is defined as `nullptr` so this causes an evaluation failure. Switch the default to overcome this issue (actually, currently lldb evaluates both C++11 and C++14 as C++11, but that seems a larger change and definitely could be re-evaluated in the future). No test as this is currently failing on the LLDB bots after the clang switch (so, de facto, there's a test already for it). This is a recommit, with a thinko fixed (the code was previously placed incorrectly). <rdar://problem/36011995> llvm-svn: 320778
* [ExpressionParser] Rollback C++98 as the standard for evaluating.Davide Italiano2017-12-151-8/+0
| | | | | | | Some ubuntu bots are failing with this patch in, let me unblock while I investigate. llvm-svn: 320769
* [ExpressionParser] Fix evaluation failures due to mismatch in C++ versions.Davide Italiano2017-12-141-0/+8
| | | | | | | | | | | | | | | | | | | | Clang recently switched to C++14 (with GNU extensions) as the default dialect, but LLDB didn't catch up. This causes failures as LLDB still evaluates ObjectiveC expressions as Objective C++ using C++98 as standard. There are things not available in C++98, including, e.g. nullptr. In some cases Objective-C `nil` is defined as `nullptr` so this causes an evaluation failure. Switch the default to overcome this issue (actually, currently lldb evaluates both C++11 and C++14 as C++11, but that seems a larger change and definitely could be re-evaluated in the future). No test as this is currently failing on the LLDB bots after the clang switch (so, de facto, there's a test already for it). <rdar://problem/36011995> llvm-svn: 320761
* ObjectFile: remove ReadSectionData/MemoryMapSectionData mutual recursionPavel Labath2017-12-141-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: These two functions were calling each other, while handling different branches of the if(IsInMemory()). This had a reason at some point in the past, but right now it's just confusing. I resolve this by removing the MemoryMapSectionData function and inlining the !IsInMemory branch into ReadSectionData. There isn't anything mmap-related in this function anyway, as the decision whether to mmap is handled at a higher level. This is a preparatory step to make ObjectFileELF be able to decompress compressed sections (I want to make sure that all calls reading section data are routed through a single piece of code). Reviewers: clayborg Subscribers: emaste, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D41169 llvm-svn: 320705
* Remove stderr message from GDBRemoteCommunicationServerLLGSPavel Labath2017-12-141-7/+2
| | | | | | | | A similar error message is printed again in lldb-gdbserver.cpp, so the user will see the message twice. Also, this is generic library code, we shouldn't really be using stderr here. llvm-svn: 320704
* Avoid module import in a textual header, NFCVedant Kumar2017-12-121-5/+2
| | | | | | This unbreaks the lldb modules build (-DLLVM_ENABLE_MODULES=On). llvm-svn: 320456
* Fix osx build broken in r320346Pavel Labath2017-12-111-1/+0
| | | | llvm-svn: 320349
* Move PseudoTerminal to the lldb_private namespacePavel Labath2017-12-116-8/+7
| | | | | | | lldb_utility doesn't make sense, as it is no longer even living in the "utility" module. llvm-svn: 320346
* [DarwinLog] Remove other dead code. Found while reading this file.Davide Italiano2017-12-101-54/+0
| | | | llvm-svn: 320338
* [MachException] Garbage collect unused and dead code.Davide Italiano2017-12-101-27/+0
| | | | llvm-svn: 320337
* Change the ordering that we search for kexts and kernels on the localJason Molenda2017-12-091-7/+22
| | | | | | | | | | | | | | | | | | | | | computer. When doing kernel debugging, lldb scrapes around a few well-known locations to find kexts and kernels. It builds up two lists - kexts and kernels with dSYM, and kexts and kernels without dSYMs. After both lists have failed to provide a file, then we'll call out to things like the DebugSymbols framework to find a kext/kernel. This meant that when you had a kext/kernel on the local computer that did not have debug information, lldb wouldn't consult DebugSymbols etc once it'd locked on to one of these no-debug-info binaries on the local computer. Reorder this so we give DebugSymbols etc a shot at finding a debug-info file before we use any of the no-debug-info binaries that were found on the system. <rdar://problem/34434440> llvm-svn: 320241
* Update PlatformDarwin::GetDeveloperDir to handle the twoJason Molenda2017-12-091-8/+13
| | | | | | | | | | | | | | | | | most common cases where the Xcode.app bundle puts lldb - either as a default part of the bundle, or in a toolchain subdirectory, so the platform subclasses can find files relative to this directory. Dropped support for handling the case where the lldb framework was in /Library/PrivateFrameworks. I think this was intended to handle the case where lldb is installed in / (outside the Xcode.app bundle) - but in that case, we can look in the raw directory file paths to find anything. <rdar://problem/35285622> llvm-svn: 320240
* Remove extant references to g_message_mutex, NFCVedant Kumar2017-12-081-8/+0
| | | | | | Thanks to Jim Ingham for providing the explanation! llvm-svn: 320126
* Disable warnings related to anonymous types in the ObjC pluginVedant Kumar2017-12-071-0/+12
| | | | | | | | | | | This part of lldb make use of anonymous structs and unions. The usage is idiomatic and doesn't deserve a warning. Logic in the NSDictionary and NSSet plugins use anonymous structs in a manner consistent with the relevant Apple frameworks. Differential Revision: https://reviews.llvm.org/D40757 llvm-svn: 320071
* Fix const-correctness in RegisterContext methods, NFCVedant Kumar2017-12-063-10/+30
| | | | | | | | | | A few methods in RegisterContext classes accept const objects which are cast to a non-const thread_state_t. Drop const-ness more explicitly where we mean to do so. This fixes a slew of warnings. Differential Revision: https://reviews.llvm.org/D40821 llvm-svn: 319939
* Remove no-op function pointer null checks, NFCVedant Kumar2017-12-062-20/+7
| | | | | | | | | | | | | | Null-checking functions which aren't marked weak_import is a no-op (the compiler rewrites the check to 'true'), regardless of whether a library providing its definition is weak-linked. If the deployment target is greater than the minimum requirement, the availability markup on APIs does not lower to weak_import. Remove no-op null checks to clean up the code and silence warnings. Differential Revision: https://reviews.llvm.org/D40812 llvm-svn: 319936
OpenPOWER on IntegriCloud