summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb] Also include the array definition in Properties.incJonas Devlieghere2019-07-2915-129/+102
| | | | | | | | | | | | | | | | Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
* SymbolVendor: Make SectionAddressesChanged a passthroughPavel Labath2019-07-292-14/+15
| | | | | | | | | | | | | | | Summary: This moves the implementation of the function into the SymbolFile class, making it possible to excise the SymbolVendor passthrough functions in follow-up patches. Reviewers: clayborg, jingham, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65266 llvm-svn: 367231
* [lldb][NFC] Remove DiagnosticManager::CopyDiagnosticsRaphael Isemann2019-07-291-9/+0
| | | | | | | | | The Diagnostic class in LLDB is suppossed to be inherited from, so just copying the diagnostics like this is wrong. The function is also unused, so lets just get rid of it instead of creating some cloning facility for it. llvm-svn: 367201
* [lldb] Also include the array definition in CommandOptions.incRaphael Isemann2019-07-2819-194/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
* [TableGen] Fix stale include pathsJonas Devlieghere2019-07-262-8/+8
| | | | | | | This worked locally because the include files were not regenerated, but fails when performing a clean build. llvm-svn: 367152
* [TableGen] Move core properties into a separate file (NFC)Jonas Devlieghere2019-07-262-1/+129
| | | | | | | With the plugins having their own tablgen file, it makes sense to split off the core properties as well. llvm-svn: 367140
* [TableGen] Move target properties into a separate file (NFC)Jonas Devlieghere2019-07-266-13/+257
| | | | | | | With the plugins having their own tablgen file, it makes sense to split off the target properties as well. llvm-svn: 367139
* [TableGen] Move interpreter properties into a separate file (NFC)Jonas Devlieghere2019-07-263-3/+41
| | | | | | | With the plugins having their own tablgen file, it makes sense to split off the interpreter properties as well. llvm-svn: 367138
* DWARF: Improve type safety or range lists parsingPavel Labath2019-07-265-16/+10
| | | | | | | | | Delete the abstract GetOffset function, which is only defined for rnglists entries. Instead fix up entries which refer to the range list classes so that one can statically know that he is dealing with the rnglists section and call the function that way. llvm-svn: 367106
* [lldb] Don't dynamically allocate the posix option validator.Raphael Isemann2019-07-263-23/+14
| | | | | | | | We dynamically allocate the option validator which means we can't mark this list of OptionDefinitions as constexpr. It's also more complicated than necessary. llvm-svn: 367102
* Fix some "control reaches end of non-void function" warningsPavel Labath2019-07-261-0/+2
| | | | llvm-svn: 367095
* ObjectFileELF: Use llvm::JamCRC to refactor CRC32 computationFangrui Song2019-07-261-67/+9
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D65318 llvm-svn: 367090
* SymbolVendor: Move Symtab construction into the SymbolFilePavel Labath2019-07-262-30/+19
| | | | | | | | | | | | | | | Summary: Instead of having SymbolVendor coordinate Symtab construction between Symbol and Object files, make the SymbolVendor function a passthrough, and put all of the logic into the SymbolFile. Reviewers: clayborg, JDevlieghere, jingham, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65208 llvm-svn: 367086
* [CMake] Add TableGen dependency to lldbInterpreter.Jonas Devlieghere2019-07-251-0/+2
| | | | | | lldbInterpreter depends on LLDBPropertiesGen and LLDBPropertiesEnumGen. llvm-svn: 367073
* Let tablegen generate property definitionsJonas Devlieghere2019-07-2530-561/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
* [LLDB] Find debugserver in Command Line Tools as wellAntonio Afonso2019-07-251-50/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This might be an edge case in regular use but if you're shipping an lldb version with no debugserver lldb will try to use the System one. However, lldb only knows how to find the Xcode one and not the Command Line Tools one. This diff fixes that. We try to find debugserver with `PlatformDarwin::LocateExecutable("debugserver")`, we call `xcode-select -p` to get the path and then assume this path is of Xcode. The changes I did are: * Change `PlatformDarwin::LocateExecutable` to also add the Command Line Tools directory to the list of paths to search for debugserver. * Created a new function to find the Command Line Tools directory named `GetCommandLineToolsLibraryPath`. * Refactored the code that calls `xcode-select -p` into its own function `GetXcodeSelectPath()`. There were 2 identical pieces of code for this so I reduced it to one and used this function everywhere instead. * I also changed `PlatformDarwin::GetSDKDirectoryForModules` to use the `SDKs` directory that exists in the Command Line Tools installation. I'm not sure how to create tests for this. PlatformDarwinTest is really limited and I couldn't find how to mock Filesystem::Instance() so I could create a virtual file system. Reviewers: clayborg, JDevlieghere Reviewed By: clayborg, JDevlieghere Subscribers: jasonmolenda, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65171 llvm-svn: 367052
* [lldb] [Process/NetBSD] Report stopped process on SIGSTOPMichal Gorny2019-07-251-0/+1
| | | | | | | | | | | | | Mark the process as stopped when SIGSTOP arrives. This is necessary for lldb-server to generate correct response to 'process interrupt', and therefore to prevent the whole stack crashing when process is stopped. Thanks to Pavel Labath for the tip. Differential Revision: https://reviews.llvm.org/D65289 llvm-svn: 367047
* Correctly use GetLoadedModuleList to take advantage of libraries-svr4Antonio Afonso2019-07-256-86/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Here's a replacement for D62504. I thought I could use LoadModules to implement this but in reality I can't because there are at few issues with it: * The LoadModules assumes that the list returned by GetLoadedModuleList is comprehensive in the sense that reflects all the mapped segments, however, this is not true, for instance VDSO entry is not there since it's loaded manually by LoadVDSO using GetMemoryRegionInfo and it doesn't represent a specific shared object in disk. Because of this LoadModules will unload the VDSO module. * The loader (interpreter) module might have also been loaded using GetMemoryRegionInfo, this is true when we launch the process and the rendezvous structure is not yet available (done through LoadInterpreterModule()). The problem here is that this entry will point to the same file name as the one found in /proc/pid/maps, however, when we read the same module from the r_debug.link_map structure it might be under a different name. This is true at least on CentOS where the loader is a symlink. Because of this LoadModules will unload and load the module in a way where the rendezvous breakpoint is unresolved but not resolved again (because we add the new module first and remove the old one after). The symlink issue might be fixable by first unloading the old and loading the news (but sounds super brittle), however, I'm not sure how to fix the VDSO issue. Since I can't trust it I'm just going to use GetLoadedModuleList directly with the same logic that we use today for when we read the linked list in lldb. The only safe thing to do here is to only calculate differences between different snapshots of the svr4 packet itself. This will also cut the dependency this plugin has from LoadModules. I separated the 2 logics into 2 different functions (remote and not remote) because I don't like mixing 2 different logics in the same function with if/else's. Two different functions makes it easier to reason with I believe. However, I did abstract away the logic that decides if we should take a snapshot or add/remove modules so both functions could reuse it. The other difference between the two is that on the UpdateSOEntriesFromRemote I take the snapshot only once when state = Consistent because I didn't find a good reason to always update that, as we already got the list from state = Add | Remove. I probably should use the same logic on UpdateSOEntries though I don't see a reason not to since it's really using the same data, just read in different places. Any thoughts here? It might also be worthwhile to add a test to make sure we don't unload modules that were not actually "unloaded" like the vdso. I haven't done this yet though. This diff is also missing the option for svr4 like proposed in https://reviews.llvm.org/D62503#1564296, I'll start working on this but wanted to have this up first. Reviewers: labath, jankratochvil, clayborg, xiaobai Reviewed By: labath Subscribers: srhines, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64013 llvm-svn: 367020
* [lldb] Tablegenify expr/frame/log/register/memoryRaphael Isemann2019-07-256-70/+161
| | | | llvm-svn: 367009
* SymbolFile: Fix -Wunused-variable in -DLLVM_ENABLE_ASSERTIONS=off builds ↵Fangrui Song2019-07-251-0/+1
| | | | | | after D65089/r366791 llvm-svn: 367001
* SymbolVendor: Remove the type list memberPavel Labath2019-07-2511-46/+19
| | | | | | | | | | | | | | | | | | | | | Summary: Similarly to the compile unit lists, the list of types can also be managed by the symbol file itself. Since the only purpose of this list seems to be to maintain an owning reference to all the types a symbol file has created (items are only ever added to the list, never retrieved), I remove the passthrough functions in SymbolVendor and Module. I also tighten the interface of the function (return a reference instead of a pointer, make it protected instead of public). Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65135 llvm-svn: 366994
* LLGS: fix tracking execve on linuxPavel Labath2019-07-251-6/+3
| | | | | | | | | | | | | | | | | | | Summary: Due to a logic error, lldb-server ended up asserting/crashing every time the debugged process attempted an execve(). This fixes the error, and extends TestExec to work on other platforms too. The "extension" consists of avoiding non-standard posix_spawn extensions and using the classic execve() call, which should be available on any platform that actually supports re-execing. I change the test decorator from @skipUnlessDarwin to @skipIfWindows. Reviewers: clayborg, jasonmolenda Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65207 llvm-svn: 366985
* [FileCollector] Remove LLDB shim around llvm::FileCollector (NFC)Jonas Devlieghere2019-07-252-5/+5
| | | | | | | | The FileCollector got lifted into LLVM and a shim was introduced in LLDB to keep the old API that takes FileSpecs. This patch removes that shim and converts the arguments in place. llvm-svn: 366975
* [FileSystem] Fix ambiguous symbol on Windows.Jonas Devlieghere2019-07-251-1/+1
| | | | | | | The using declarations make FileCollector ambiguous. Specify that FileSystem takes an lldb_private::FileCollector. llvm-svn: 366974
* [FileCollector] Change coding style from LLDB to LLVM (NFC)Jonas Devlieghere2019-07-252-3/+3
| | | | | | | | This patch changes the coding style of the FileCollector from the LLDB to the LLVM coding style. Alex recently lifted it into LLVM and I volunteered to do the conversion. llvm-svn: 366966
* [Support] move FileCollector from LLDB to llvm/SupportAlex Lorenz2019-07-242-183/+0
| | | | | | | | | The file collector class is useful for creating reproducers, not just for LLDB, but for other tools as well in LLVM/Clang. Differential Revision: https://reviews.llvm.org/D65237 llvm-svn: 366956
* [Symbol] Fix some botched logic in Variable::GetLanguageAlex Langford2019-07-241-5/+5
| | | | | | | | | | | | | | Summary: I messed up the logic for this. Fixing with some improvements suggested by Pavel. Reviewers: labath, jdoerfert Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65165 llvm-svn: 366950
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-24186-5927/+5350
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* [lldb] Fix build errors from tablegenify platform commitRaphael Isemann2019-07-242-9/+9
| | | | | | Forgot to stage some changes... llvm-svn: 366892
* [lldb][NFC] Tablegenify platformRaphael Isemann2019-07-242-46/+112
| | | | llvm-svn: 366891
* Revert "Revert "[lldb] [Process/NetBSD] Fix constructor after r363707""Michal Gorny2019-07-241-1/+1
| | | | | | The relevant changes have been reapplied, and broke build again. llvm-svn: 366889
* [ExpressionParser] Handle llvm::Expected resultJonas Devlieghere2019-07-231-2/+10
| | | | | | | | | | This fixes the unchecked-error assertion at runtime. Expected<T> must be checked before access or destruction. Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed). llvm-svn: 366853
* [ExpressionParser] Fix formatting and whitespace (NFC)Jonas Devlieghere2019-07-231-32/+32
| | | | | | Fix formatting and whitespace before making changes to this file. llvm-svn: 366852
* Revert "Revert "Add ReadCStringFromMemory for faster string reads""Antonio Afonso2019-07-233-7/+60
| | | | | | This reverts commit 9c10b620c0619611dfe062216459431955ac4801. llvm-svn: 366848
* Revert "Revert "Implement xfer:libraries-svr4:read packet""Antonio Afonso2019-07-237-4/+126
| | | | | | This reverts commit 08c38f77c5fb4d3735ec215032fed8ee6730b3db. llvm-svn: 366847
* [Logging] Fix format stringsJonas Devlieghere2019-07-232-18/+16
| | | | | | | Change format strings to use the `{}` syntax instead of the printf syntax when using LLDB_LOG. llvm-svn: 366824
* [lldb][NFC] Tablegenify processRaphael Isemann2019-07-232-25/+62
| | | | llvm-svn: 366804
* ProcessMachCore: Fix a -Wmisleading-indentation warningPavel Labath2019-07-231-36/+35
| | | | llvm-svn: 366803
* Fix windows build after r366791Pavel Labath2019-07-231-1/+3
| | | | | | | | | | | | A side effect of this commit was that it exchanged the order of types and compile units in the output of SymbolVendor::Dump. A couple of PDB tests dependened on that to assert the links between the two. While it wouldn't be too hard to update the tests, the change of ordering was not something I intended to do with that patch, and is easy to restore the original order, so I do just that. llvm-svn: 366798
* [lldb][NFC] Tablegenify sourceRaphael Isemann2019-07-232-19/+46
| | | | llvm-svn: 366795
* SymbolVendor: Move compile unit handling into the SymbolFile classPavel Labath2019-07-2314-130/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SymbolFile classes are responsible for creating CompileUnit instances and they already need to have a notion of the id<->CompileUnit mapping (because of APIs like ParseCompileUnitAtIndex). However, the SymbolVendor has remained as the thing responsible for caching created units (which the SymbolFiles were calling via convoluted constructs like "m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)"). This patch moves the responsibility of caching the units into the SymbolFile class. It does this by moving the implementation of SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the equivalent SymbolFile functions. The SymbolVendor functions become just a passthrough much like the rest of SymbolVendor. The original implementations of SymbolFile::GetNumCompileUnits is moved to "CalculateNumCompileUnits", and are made protected, as the "Get" function is the external api of the class. SymbolFile::ParseCompileUnitAtIndex is made protected for the same reason. This is the first step in removing the SymbolVendor indirection, as proposed in <http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After removing all interesting logic from the SymbolVendor class, I'll proceed with removing the indirection itself. Reviewers: clayborg, jingham, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65089 llvm-svn: 366791
* [lldb][NFC] Tablegenify disassembleRaphael Isemann2019-07-232-24/+41
| | | | llvm-svn: 366783
* [Logging] Replace LogIfAnyCategoriesSet with LLDB_LOG.Jonas Devlieghere2019-07-224-61/+32
| | | | | | | | This patch removes any remaining instances of LogIfAnyCategoriesSet and replaces them with the LLDB_LOG macro. This in turn made it possible to make Log::VAPrintf and Log::VAError private. llvm-svn: 366768
* [Symbol] Improve Variable::GetLanguageAlex Langford2019-07-222-14/+14
| | | | | | | | | | | | | | | | Summary: When trying to ascertain what language a variable belongs to, just checking the compilation unit is often not enough. In r364845 I added a way to check for a variable's language type, but didn't put it in Variable itself. Let's go ahead and put it in Variable. Reviewers: jingham, clayborg Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D64042 llvm-svn: 366733
* [Windows] Fix race condition between state changesAdrian McCarthy2019-07-221-11/+10
| | | | | | | | | | | | | | | Patch by Martin Andersson (martin.andersson@evoma.se) If the process is resumed before the state is changed to "running" there is a possibility (when single stepping) that the debugger stops and changes the state to "stopped" before it is first changed to "running". This causes the process to ignore the stop event (since the state did not change) which in turn leads the DebuggerThread to wait indefinitely for the exception predicate in HandleExceptionEvent. Differential Revision: https://reviews.llvm.org/D62183 llvm-svn: 366703
* ELF: Fix a "memset clearing object of non-trivial type" warningPavel Labath2019-07-222-16/+3
| | | | | | | | Just delete the memset as the ELFHeader constructor already zero-initializes the object. Also clean up the ObjectFileELF constructors/desctructors while I'm in there. llvm-svn: 366692
* [lldb][NFC] Tablegenify breakpointRaphael Isemann2019-07-223-136/+265
| | | | llvm-svn: 366673
* [lldb] Fix crash when looking up type coming from the ClangModuleDeclVendorRaphael Isemann2019-07-211-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We assume in LLDB that every type comes from an ASTContext with an associated ClangASTContext. However the types inside the ClangModuleDeclVendor don't have a ClangASTContext so we end up crashing whenever we create a CompilerType for one of these types. Simplest way to trigger this bug is to just look up NSObject from a module: (lldb) expr @import Foundation (lldb) type lookup NSObject Assertion failed: (m_type_system != nullptr), function CompilerType, file /Users/teemperor/llvm1/llvm-project/lldb/source/Symbol/CompilerType.cpp, line 39. This patch just creates a ClangASTContext for the ASTContext used by ClangModuleDeclVendor. Reviewers: davide, shafik Reviewed By: davide Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64989 llvm-svn: 366653
* [NativePDB] Make GetOrCreateDeclForUid return an lldb CompilerDeclNathan Lanza2019-07-213-12/+16
| | | | | | | | | We intend to make PdbAstBuilder abstract and implement PdbAstBuilderClang along with any other languages that wish to use PDBs. Thus, change GetOrCreateDeclForUid from returning a clang decl to a lldb_private::CompilerDecl. llvm-svn: 366650
* [lldb] Fix buildbot build fail caused by r366645Yuanfang Chen2019-07-211-2/+2
| | | | llvm-svn: 366647
OpenPOWER on IntegriCloud