summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/Module.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/ScriptInterpreter] Remove can_reload which is always true (NFC)Jonas Devlieghere2019-12-221-3/+1
| | | | | | The `-r` option for `command script import` is there for legacy compatibility, however the can_reload flag is always set to true. This patch removes the flag and any code that relies on it being false.
* [lldb][NFC] Migrate FileSpec::Dump to raw_ostreamRaphael Isemann2019-12-061-1/+1
|
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-041-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The FileSpec class is often used as a sort of a pattern -- one specifies a bare file name to search, and we check if in matches the full file name of an existing module (for example). These comparisons used FileSpec::Equal, which had some support for it (via the full=false argument), but it was not a good fit for this job. For one, it did a symmetric comparison, which makes sense for a function called "equal", but not for typical searches (when searching for "/foo/bar.so", we don't want to find a module whose name is just "bar.so"). This resulted in patterns like: if (FileSpec::Equal(pattern, file, pattern.GetDirectory())) which would request a "full" match only if the pattern really contained a directory. This worked, but the intended behavior was very unobvious. On top of that, a lot of the code wanted to handle the case of an "empty" pattern, and treat it as matching everything. This resulted in conditions like: if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory()) which are nearly impossible to decipher. This patch introduces a FileSpec::Match function, which does exactly what most of FileSpec::Equal callers want, an asymmetric match between a "pattern" FileSpec and a an actual FileSpec. Empty paterns match everything, filename-only patterns match only the filename component. I've tried to update all callers of FileSpec::Equal to use a simpler interface. Those that hardcoded full=true have been changed to use operator==. Those passing full=pattern.GetDirectory() have been changed to use FileSpec::Match. There was also a handful of places which hardcoded full=false. I've changed these to use FileSpec::Match too. This is a slight change in semantics, but it does not look like that was ever intended, and it was more likely a result of a misunderstanding of the "proper" way to use FileSpec::Equal. [In an ideal world a "FileSpec" and a "FileSpec pattern" would be two different types, but given how widespread FileSpec is, it is unlikely we'll get there in one go. This at least provides a good starting point by centralizing all matching behavior.] Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70851
* [lldb][NFC] Migrate to raw_ostream in Module::GetDescriptionRaphael Isemann2019-12-041-10/+11
|
* [lldb] Remove FileSpec->CompileUnit inheritancePavel Labath2019-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: CompileUnit is a complicated class. Having it be implicitly convertible to a FileSpec makes reasoning about it even harder. This patch replaces the inheritance by a simple member and an accessor function. This avoid the need for casting in places where one needed to force a CompileUnit to be treated as a FileSpec, and does not add much verbosity elsewhere. It also fixes a bug where we were wrongly comparing CompileUnit& and a CompileUnit*, which compiled due to a combination of this inheritance and the FileSpec*->FileSpec implicit constructor. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70827
* Performance: Add a set of visited SymbolFiles to the other FindFiles variant.Adrian Prantl2019-11-121-3/+5
| | | | | | | | | | | | | | This is basically the same bug as in r260434. SymbolFileDWARF::FindTypes has exponential worst-case when digging through dependency DAG of .pcm files because each object file and .pcm file may depend on an already-visited .pcm file, which may again have dependencies. Fixed here by carrying a set of already visited SymbolFiles around. rdar://problem/56993424 Differential Revision: https://reviews.llvm.org/D70106
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-171-50/+26
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* Remove size_t return parameter from FindTypesAdrian Prantl2019-10-011-30/+20
| | | | | | | | | | | | | | | In r368345 I accidentally introduced a regression that would over-report the number of matches found by FindTypes if the DeclContext Filter was hit. This patch simply removes the size_t return parameter altogether — it's not that useful. rdar://problem/55500457 Differential Revision: https://reviews.llvm.org/D68169 llvm-svn: 373344
* Remove unused "append" parameter from FindTypes APIAdrian Prantl2019-09-301-12/+9
| | | | | | | | | | | | | 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
* Upstream macCatalyst support in debugserver and the macOS dynamic loaderAdrian Prantl2019-09-041-0/+20
| | | | | | | | | | | 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
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-0/+9
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-2/+2
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* Remove Module::GetSymbolVendorPavel Labath2019-08-081-13/+6
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymbolVendor function, and the various mentions of the SymbolVendor in the Module class. The implementation of GetSymbolVendor is "inlined" into the GetSymbolFile class which I created earlier. After this patch, the SymbolVendor class still exists inside the Module object, but only as an implementation detail -- a fancy holder for the SymbolFile. That will be removed in the next patch. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D65864 llvm-svn: 368263
* Remove SymbolVendor::GetSymtabPavel Labath2019-08-051-34/+23
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it creates a Module::GetSymtab, which calls the SymbolFile method directly. All callers have been updated to use the Module method directly instead of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced intentation in a lot of deeply nested code. Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65569 llvm-svn: 367820
* SymbolVendor: Introduce Module::GetSymbolFilePavel Labath2019-08-021-43/+37
| | | | | | | | | | | | | | | | | | | | | Summary: This is the next step in avoiding funneling all SymbolFile calls through the SymbolVendor. Right now, it is just a convenience function, but it allows us to update all calls to SymbolVendor functions to access the SymbolFile directly. Once all call sites have been updated, we can remove the GetSymbolVendor member function. This patch just updates the calls to GetSymbolVendor, which were calling it just so they could fetch the underlying symbol file. Other calls will be done in follow-ups. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65435 llvm-svn: 367664
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-301-1/+2
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* SymbolVendor: Remove the type list memberPavel Labath2019-07-251-7/+0
| | | | | | | | | | | | | | | | | | | | | 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
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-19/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ScriptInterpreter] Move ownership into debugger (NFC)Jonas Devlieghere2019-04-261-2/+1
| | | | | | | | | | | | | | This is part two of the change started in r359330. This patch moves the ownership of the script interpreter from the command interpreter into the debugger. I would've preferred to remove the lazy initialization, however the fact that the scripting language is set after the debugger is created makes that tricky. So for now this does exactly the same thing as when it was under the command interpreter. The result is that this patch is fully NFC. Differential revision: https://reviews.llvm.org/D61211 llvm-svn: 359354
* Correctly check if a warning message lacks a trailing new lineRaphael Isemann2019-04-161-3/+3
| | | | | | | | | | | | | | | | Summary: Fixes LLVM bug 41489. Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60653 llvm-svn: 358477
* Reinitialize UnwindTable when the SymbolFile changesPavel Labath2019-03-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory step to enable adding of unwind plans by symbol file plugins. Although at the surface it seems that currently symbol files have nothing to do with unwinding, this isn't entirely correct even now. The mere act of adding a symbol file can have the effect of making more sections (typically .debug_frame) available to the unwinding machinery, so that it can have more unwind strategies to choose from. Up until now, we've had a bug, which went largely unnoticed, where unwind info in the manually added symbols files (target symbols add) was being ignored during unwinding. Reinitializing the UnwindTable fixes that bug too. Reviewers: clayborg, jasonmolenda, alexshap Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58347 llvm-svn: 356361
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-13/+13
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Merge target triple into module triple when constructing module from memoryAlex Langford2019-02-201-0/+4
| | | | | | | | | | | | | | | | | | | Summary: While debugging an android process remotely from a windows machine, I noticed that the modules constructed from an object file in memory only had information about the architecture. Without knowledge of the OS or environment, expression evaluation sometimes leads to incorrectly generated code or a debugger crash. While we cannot know for certain what triple a module constructed from an in-memory object file will have, we can use the triple from the target to try and fill in the missing details. Reviewers: clayborg, zturner, JDevlieghere, compnerd, aprantl, labath Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58405 llvm-svn: 354526
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-18/+18
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Simplify ObjectFile::GetUUIDPavel Labath2019-02-111-1/+1
| | | | | | | | | instead of returning the UUID through by-ref argument and a boolean value indicating success, we can just return it directly. Since the UUID class already has an invalid state, it can be used to denote the failure without the additional bool. llvm-svn: 353714
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-141-21/+23
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.Zachary Turner2019-01-141-2/+3
| | | | | | | | | | | | | This method took a SymbolContext but only actually cared about the case where the m_function member was set. Furthermore, it was intended to be implemented to parse blocks recursively despite not documenting this in its name. So we change the name to indicate that it should be recursive, while also limiting the function parameter to be a Function&. This lets the caller know what is required to use it, as well as letting new implementers know what kind of inputs they need to be prepared to handle. llvm-svn: 351131
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-111-14/+14
| | | | | | | | | | | | | | | | Previously all of these functions accepted a SymbolContext&. While a CompileUnit is one member of a SymbolContext, there are also many others, and by passing such a monolithic parameter in this way it makes the requirements and assumptions of the API unclear for both callers as well as implementors. All these methods need is a CompileUnit. By limiting the parameter type in this way, we simplify the code as well as make it self-documenting for both implementers and users. Differential Revision: https://reviews.llvm.org/D56564 llvm-svn: 350943
* Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.Zachary Turner2019-01-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The function SymbolFile::ParseTypes previously accepted a SymbolContext. This makes it extremely difficult to implement faithfully, because you have to account for all possible combinations of members being set in the SymbolContext. On the other hand, no clients of this function actually care about implementing this function to this strict of a standard. AFAICT, there is actually only 1 client in the entire codebase, and it is the function ParseAllDebugSymbols, which is itself only called for testing purposes when dumping information. At this call-site, the only field it sets is the CompileUnit, meaning that an implementer of a SymbolFile need not worry about any examining or handling any other fields which might be set. By restricting this API to accept exactly a CompileUnit& and nothing more, we can simplify the life of new SymbolFile plugin implementers by making it clear exactly what the necessary and sufficient set of functionality they need to implement is, while at the same time removing some dead code that tried to handle other types of SymbolContext fields that were never going to be set anyway. Differential Revision: https://reviews.llvm.org/D56462 llvm-svn: 350889
* Simplify ObjectFile::GetArchitecturePavel Labath2019-01-031-4/+2
| | | | | | | | | | | | | | | | Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
* [NFC] Replace `compare` with (in)equality operator where applicable.Jonas Devlieghere2018-12-211-1/+1
| | | | | | | | Using compare is verbose, bug prone and potentially inefficient (because of early termination). Replace relevant call sites with the (in)equality operator. llvm-svn: 349972
* Remove comments after header includes.Jonas Devlieghere2018-11-111-26/+26
| | | | | | | | | | This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
* [FileSystem] Add convenience method to check for directories.Jonas Devlieghere2018-11-081-1/+1
| | | | | | | | | | | Replace calls to LLVM's is_directory with calls to LLDB's FileSytem class. For this I introduced a new convenience method that, like the other methods, takes either a path or filespec. This still uses the LLVM functions under the hood. Differential revision: https://reviews.llvm.org/D54135 llvm-svn: 346375
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-1/+1
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* [FileSystem] Remove Exists() from FileSpecJonas Devlieghere2018-11-011-2/+3
| | | | | | | | | This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53845 llvm-svn: 345854
* [FileSystem] Remove GetByteSize() from FileSpecJonas Devlieghere2018-11-011-1/+2
| | | | | | | | | This patch removes the GetByteSize method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53788 llvm-svn: 345812
* [FileSystem] Extend file system and have it use the VFS.Jonas Devlieghere2018-10-311-5/+5
| | | | | | | | | | | | | | | | This patch extends the FileSystem class with a bunch of functions that are currently implemented as methods of the FileSpec class. These methods will be removed in future commits and replaced by calls to the file system. The new functions are operated in terms of the virtual file system which was recently moved from clang into LLVM so it could be reused in lldb. Because the VFS is stateful, we turned the FileSystem class into a singleton. Differential revision: https://reviews.llvm.org/D53532 llvm-svn: 345783
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-251-6/+8
| | | | | | | | | | This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
* Don't type-erase the SymbolContextItem enumeration.Zachary Turner2018-10-251-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is. The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly. This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean. Differential Revision: https://reviews.llvm.org/D53597 llvm-svn: 345313
* Use a DenseMap for looking up functions by UID in CompileUnit::FindFunctionByUIDRaphael Isemann2018-08-111-6/+4
| | | | | | | | | | | | | | | | | | Summary: Instead of iterating over our vector of functions, we might as well use a map here to directly get the function we need. Thanks to Vedant for pointing this out. Reviewers: vsk Reviewed By: vsk Subscribers: mgrang, lldb-commits Differential Revision: https://reviews.llvm.org/D50225 llvm-svn: 339504
* Misc module/dwarf logging improvementsLeonard Mosescu2018-08-071-2/+6
| | | | | | | | | | | | | | This change improves the logging for the lldb.module category to note a few interesting cases: 1. Local object file found, but specs not matching 2. Local object file not found, using a placeholder module The handling and logging for the cases wehre we fail to load compressed dwarf symbols is also improved. Differential Revision: https://reviews.llvm.org/D50274 llvm-svn: 339161
* Use llvm::VersionTuple instead of manual version marshallingPavel Labath2018-06-181-10/+4
| | | | | | | | | | | | | | | | | | Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
* Fix Module::FindTypes to return the correct number of matches.Frederic Riss2018-06-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | In r331719, I changed Module::FindTypes not to limit the amount of types returned by the Symbol provider, because we want all possible matches to be able to filter them. In one code path, the filtering was applied to the TypeList without changing the number of types that gets returned. This is turn could cause consumers to access beyond the end of the TypeList. This patch fixes this case and also adds an assertion to TypeList::GetTypeAtIndex to catch those obvious programming mistakes. Triggering the condition in which we performed the incorrect access was not easy. It happened a lot in mixed Swift/ObjectiveC code, but I was able to trigger it in pure Objective C++ although in a contrieved way. rdar://problem/40254997 llvm-svn: 333786
* Remove append parameter to FindGlobalVariablesPavel Labath2018-05-311-5/+5
| | | | | | | | | | | | | | | | | | | Summary: As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317, FindGlobalVariables does not properly handle the case where append=false. As this doesn't seem to be used in the tree, this patch removes the parameter entirely. Reviewers: clayborg, jingham, labath Reviewed By: clayborg Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere Differential Revision: https://reviews.llvm.org/D46885 Patch by Tom Tromey <ttromey@mozilla.com>. llvm-svn: 333639
* Break dependency from Core to ObjectFileJIT.Zachary Turner2018-05-231-21/+0
| | | | | | | | | | | | | | | | | | The only reason this was here was so that Module could have a function called CreateJITModule which created things in a special order. Instead of making this specific to creating JIT modules, I converted this into a template function that can create a module for any type of object file plugin and just forwards arguments through. Since the template is not instantiated in Core, the linker (and header file) dependency moves to the point where it is instantiated, which only happens in Expression. Conceptually, this location also makes more sense for a dependency on ObjectFileJIT. After all, we JIT expressions so it's no surprise that Expression needs to make use of ObjectFileJIT. Differential Revision: https://reviews.llvm.org/D47228 llvm-svn: 333143
* Really test type lookup in TestCppTypeLookup.pyFrederic Riss2018-05-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ... and fix one bug found this way. Currently, the test works not because types are looked up correctly, but because by injecting local variables we also materialize the types for Clang. If we disable the local variable injection, then one check fails. The reason of the failure is that FindTypes is run with max_matches==1 and this value is passed down to the symbol lookup functions. When the search is performed only on the basename (like it's the case for an entity defined in the root namespace), then the search will stop after having found one match on the basename. But that match might be in a namespace, we were really just looking up the basename in the accelerator tables. The solution is to not pass max_matches down, but to search without a limit and let RemoveMismatchedTypes do its job afterwards. Note the patch includes 2 hunks with the same change, but only the latter is tested. I couldn't find a way to create a testcase for the other branch of the if ('image lookup -t' allows me to get there, but it only ever returns one type anyway). Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46548 llvm-svn: 331719
* Use conventional spelling of always-failing assert.Richard Smith2018-05-021-1/+1
| | | | | | Fixes -Wstring-conversion warning that was breaking -Werror builds. llvm-svn: 331406
* Use the UUID from the minidump's CodeView Record for placeholder modulesLeonard Mosescu2018-05-021-3/+14
| | | | | | | | | | | | | | | This change adds support for two types of Minidump CodeView records: PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html) This is by far the most common record type. ELF BuildID (found in Breakpad/Crashpad generated minidumps) This would set a proper UUID for placeholder modules, in turn enabling an accurate match with local module images. Differential Revision: https://reviews.llvm.org/D46292 llvm-svn: 331394
* Fix expression parser to not accept any type whose basename matches for a ↵Greg Clayton2018-04-301-2/+8
| | | | | | | | | | type that must exist at root level This patch fixes an issue where we weren't looking for exact matches in the expression parser and also fixed the type lookup logic in the Module.cpp. Tests added to make sure we don't regress. Differential Revision: https://reviews.llvm.org/D46128 llvm-svn: 331227
OpenPOWER on IntegriCloud