summaryrefslogtreecommitdiffstats
path: root/lldb/source/Symbol
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLDB] - Improved DWARF5 support.George Rimar2018-09-131-0/+1
| | | | | | | | | This patch improves the support of DWARF5. Particularly the reporting of source code locations. Differential revision: https://reviews.llvm.org/D51935 llvm-svn: 342153
* [PDB] Restore AST from PDB symbolsAleksandr Urakov2018-09-101-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds an implementation of retrieving of declarations and declaration contexts based on PDB symbols. PDB has different type symbols for const-qualified types, and this implementation ensures that only one declaration was created for both const and non-const types, but creates different compiler types for them. The implementation also processes the case when there are two symbols corresponding to a variable. It's possible e.g. for class static variables, they has one global symbol and one symbol belonging to a class. PDB has no info about namespaces, so this implementation parses the full symbol name and tries to figure out if the symbol belongs to namespace or not, and then creates nested namespaces if necessary. Reviewers: asmith, zturner, labath Reviewed By: asmith Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D51162 llvm-svn: 341782
* [Symtab][NFC] Added llvm_unreachable to supress compiler warningDavid Bolvansky2018-09-031-0/+1
| | | | | | | | | | | | Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D51587 llvm-svn: 341315
* Support setting a breakpoint by FileSpec+Line+Column in the SBAPI.Adrian Prantl2018-08-301-7/+7
| | | | | | | | | | | | This patch extends the SBAPI to allow for setting a breakpoint not only at a specific line, but also at a specific (minimum) column. When a column is specified, it will try to find an exact match or the closest match on the same line that comes after the specified location. Differential Revision: https://reviews.llvm.org/D51461 llvm-svn: 341078
* Provide a default implementation of TypeSystem::GetNumTemplateArgumentsFrederic Riss2018-08-302-5/+4
| | | | | | | ... and remove the dummy implementations from the languages that do not support it. llvm-svn: 341006
* [NFC] Minor update to commentAleksandr Urakov2018-08-201-1/+1
| | | | | | | | Update comment after rLLDB339994 Differential Revision: https://reviews.llvm.org/D49980 llvm-svn: 340151
* Fix compiler warnings after rL339649.Aleksandr Urakov2018-08-171-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D49980 llvm-svn: 339994
* [PDB] Parse UDT symbols and pointers to members (combined patch)Aleksandr Urakov2018-08-141-10/+100
| | | | | | | | | | | | | | | | | | | | | | Summary: In this patch I've tried to combine the best ideas from D49368 and D49410, so it implements following: - Completion of UDTs from a PDB with a filling of a layout info; - Pointers to members; - Fixes the bug relating to a virtual base offset reading from `vbtable`. The offset was treated as an unsigned, but it can be a negative sometimes. - Support of MSInheritance attribute Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits Reviewed By: zturner Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D49980 llvm-svn: 339649
* Use a DenseMap for looking up functions by UID in CompileUnit::FindFunctionByUIDRaphael Isemann2018-08-111-29/+28
| | | | | | | | | | | | | | | | | | 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
* Use rich mangling information in Symtab::InitNameIndexes()Stefan Granitz2018-08-081-88/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I set up a new review, because not all the code I touched was marked as a change in old one anymore. In preparation for this review, there were two earlier ones: * https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes * https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function Primary goals for this patch are: (1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index. (2) Provide a uniform interface. (3) Improve indexing performance. The central implementation in this patch is our new function for explicit demangling: ``` const RichManglingInfo * Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *) ``` It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are: * `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`). * `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing. The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`. Future potential: * `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.) * The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages. One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess). First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think. Reviewers: labath, jingham, JDevlieghere, erik.pilkington Subscribers: zturner, clayborg, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50071 llvm-svn: 339291
* Delete a dead Function constructor (NFC)Vedant Kumar2018-08-071-11/+0
| | | | llvm-svn: 339206
* Removed duplicated commented-out code [NFC]Raphael Isemann2018-08-071-2/+0
| | | | llvm-svn: 339202
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-073-3/+3
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Add missing boundary checks to variable completion.Raphael Isemann2018-07-271-3/+4
| | | | | | | | | | Summary: Stopgap patch to at least stop all the crashes I get from this code. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49949 llvm-svn: 338177
* Narrow the CompletionRequest API to being append-only.Raphael Isemann2018-07-271-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
* Rollback r337070.Sterling Augustine2018-07-131-2/+0
| | | | | | Someone simultaneously fixed the breakage it was designed to fix. llvm-svn: 337071
* Update ClangASTContext for the new DependentVector type.Sterling Augustine2018-07-131-0/+2
| | | | | | https://reviews.llvm.org/D49326 llvm-svn: 337070
* Fix -Wswitch after introduction of clang;:Type::DependentVector in r337036Fangrui Song2018-07-131-0/+4
| | | | llvm-svn: 337063
* Replaced more boilerplate code with CompletionRequest (NFC)Raphael Isemann2018-07-131-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: As suggested in D48796, this patch replaces even more internal calls that were using the old completion API style with a single CompletionRequest. In some cases we also pass an option vector/index, but as we don't always have this information, it currently is not part of the CompletionRequest class. The constructor of the CompletionRequest is now also more sensible. You only pass the user input, cursor position and your list of matches to the request and the rest will be inferred (using the same code we used before to calculate this). You also have to pass these match window parameters to it, even though they are unused right now. The patch shouldn't change any behavior. Reviewers: jingham Reviewed By: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48976 llvm-svn: 337031
* Change AddressClass type from 'enum' to 'enum class'.Tatyana Krasnukha2018-06-261-37/+37
| | | | | | If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
* One ShortFract ought to be enough for everyone.Benjamin Kramer2018-06-141-1/+0
| | | | llvm-svn: 334755
* Add remaining fixed-point types and saturated equivalents to fix -Wswitch of ↵Fangrui Song2018-06-141-0/+19
| | | | | | r334718 llvm-svn: 334745
* [FileSpec] Make style argument mandatory for SetFile. NFCJonas Devlieghere2018-06-131-1/+1
| | | | | | | | | | | | | | | | SetFile has an optional style argument which defaulted to the native style. This patch makes that argument mandatory so clients of the FileSpec class are forced to think about the correct syntax. At the same time this introduces a (protected) convenience method to update the file from within the FileSpec class that keeps the current style. These two changes together prevent a potential pitfall where the style might be forgotten, leading to the path being updated and the style unintentionally being changed to the host style. llvm-svn: 334663
* Fix/unify the spelling of Objective-C.Adrian Prantl2018-06-131-1/+1
| | | | llvm-svn: 334614
* [DWARF] Add (empty) DebugNamesDWARFIndex class and a setting to control its usePavel Labath2018-06-061-0/+2
| | | | | | | | | | | | | | | | | | | Summary: This patch adds the skeleton for implementing the DWARF v5 name index class. All of the methods are stubbed out and will be implemented in subsequent patches. The interesting part of the patch is the addition of a "ignore-file-indexes" setting to the dwarf plugin which enables a user to force using manual indexing path in lldb (for example as a debugging aid). I have also added a test that verifies that file indexes are used by default. Reviewers: JDevlieghere, clayborg, jingham Subscribers: mgorny, mehdi_amini, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D47629 llvm-svn: 334088
* Silence unhandled enums warning in ClangASTContext::GetEncodingIlya Biryukov2018-06-051-0/+9
| | | | | | | | | The warning started firing after r333923, which added new builtin types (fixed point types) into clang. This patch merely silences the warning to unblock our integrate, does not aim to support the new types in lldb. llvm-svn: 333999
* 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
* Add .debug_names section glue codePavel Labath2018-06-011-0/+1
| | | | llvm-svn: 333743
* Remove append parameter to FindGlobalVariablesPavel Labath2018-05-312-15/+12
| | | | | | | | | | | | | | | | | | | 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
* Remove unused include, and corresponding library dependency.James Y Knight2018-05-242-2/+0
| | | | llvm-svn: 333151
* Add support to object files for accessing the .debug_types sectionGreg Clayton2018-05-081-0/+1
| | | | | | | | In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch Differential Revision: https://reviews.llvm.org/D46529 llvm-svn: 331777
* Enable AUTOBRIEF in doxygen configuration.Adrian Prantl2018-05-021-1/+1
| | | | | | | | | | | | | | This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments. This patch also reflows the paragraphs in all doxygen comments. See also https://reviews.llvm.org/D46290. Differential Revision: https://reviews.llvm.org/D46321 llvm-svn: 331373
* Update lldb to match clang r331244 (addition of char8_t).Richard Smith2018-05-021-2/+3
| | | | | | | Also fix misclassification of char16_t and char32_t: these are unsigned types, not signed types. llvm-svn: 331323
* Reflow paragraphs in comments.Adrian Prantl2018-04-3025-759/+626
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Support reading section ".gnu_debugaltlink"Jan Kratochvil2018-04-291-0/+1
| | | | | | Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
* Always normalize FileSpec paths.Greg Clayton2018-04-272-6/+4
| | | | | | | | Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
* Fix -Wswitch warning after r330790.Benjamin Kramer2018-04-251-0/+3
| | | | | | | source/Symbol/ClangASTContext.cpp:391:13: error: enumeration value 'HIP' not handled in switch [-Werror,-Wswitch] switch (IK.getLanguage()) { llvm-svn: 330823
* Support template template parametersFrederic Riss2018-04-021-0/+23
| | | | | | | | | | | | | | | | | | Summary: We would fail to resolve (and thus display the value of) any templated type which contained a template template argument even though we don't really use template arguments. This patch adds minimal support for template template arguments, but I doubt we need any more than that. Reviewers: clayborg, jingham Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D44613 llvm-svn: 328984
* Use the DWARF linkage name when importing C++ methods.Davide Italiano2018-03-271-1/+6
| | | | | | | | | | | | | | | | | | | | When importing C++ methods into clang AST nodes from the DWARF symbol table, preserve the DW_AT_linkage_name and use it as the linker ("asm") name for the symbol. Concretely, this enables `expression` to call into names that use the GNU `abi_tag` extension, and enables lldb to call into code using std::string or std::list from recent versions of libstdc++. See https://bugs.llvm.org/show_bug.cgi?id=35310 . It also seems broadly more robust than relying on the DWARF->clang->codegen pipeline to roundtrip properly, but I'm not immediately aware of any other cases in which it makes a difference. Patch by Nelson Elhage! Differential Revision: https://reviews.llvm.org/D40283 llvm-svn: 328658
* [ExpressionParser] Re-implement r327356 in a less disruptive way.Davide Italiano2018-03-201-2/+2
| | | | | | | | | | | | Instead of applying the sledgehammer of refusing to insert any C++ symbol in the ASTContext, try to validate the decl if what we have is an operator. There was other code in lldb which was responsible for this, just not really exposed (or used) in this codepath. Also, add a better/more comprehensive test. <rdar://problem/35645893> llvm-svn: 328025
* Re-land: [lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-03-201-30/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | regions The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses). Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>. llvm-svn: 327970
* [ClangASTContext] Remove dead code. NFCI.Davide Italiano2018-03-191-45/+0
| | | | llvm-svn: 327893
* Revert "[lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-02-281-21/+12
| | | | | | | | | | | | regions" This reverts commit r326261 as it introduces inconsistencies in the handling of load addresses for ObjectFileELF -- some parts of the class use physical addresses, and some use virtual. This has manifested itself as us not being able to set the load address of the vdso "module" on android. llvm-svn: 326367
* [lldb] Use vFlash commands when writing to target's flash memory regionsPavel Labath2018-02-271-12/+21
| | | | | | | | | | | | | | | | | | | | | | Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 326261
* Handle typeof() expressionsJonas Devlieghere2018-02-201-17/+65
| | | | | | | | | | | | | | | | | | | | Before this patch, LLDB was not able to evaluate expressions that resulted in a value with a typeof- or decltype-type. This patch fixes that. Before: (lldb) p int i; __typeof__(i) j = 1; j (typeof (i)) $0 = After: (lldb) p int i; __typeof__(i) j = 1; j (typeof (i)) $0 = 1 Differential revision: https://reviews.llvm.org/D43471 rdar://37461520 llvm-svn: 325568
* Make sure DataBufferLLVM contents are writablePavel Labath2017-12-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ClangASTContext] Remove dead stuff found fixing something else.Davide Italiano2017-12-141-75/+0
| | | | llvm-svn: 320759
* ObjectFile: remove ReadSectionData/MemoryMapSectionData mutual recursionPavel Labath2017-12-141-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Variable: Fix usage of uninitialised valuePavel Labath2017-12-071-7/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Variable::GetValuesForVariableExpressionPath was passing an uninitialised value for the final_task_on_target argument. On my compiler/optimization level combo, the final_task_on_target happened to contain "dereference" in some circumstances, which produced hilarious results. The same is true for other arguments to the GetValueForExpressionPath call. The correct behavior here seems to be to just omit the arguments altogether and let the default behavior take place. Reviewers: jingham Subscribers: mehdi_amini, lldb-commits Differential Revision: https://reviews.llvm.org/D40557 llvm-svn: 320021
* Fix assertion in ClangASTContextPavel Labath2017-11-303-12/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: llvm::APSInt(0) asserts because it creates an int with bit-width 0 and not (as I thought) a value 0. Theoretically it should be sufficient to change this to APSInt(1), as the intention there was that the value of the first argument should be ignored if the type is invalid, but that would look dodgy. Instead, I use llvm::Optional to denote an invalid value and use a special struct instead of a std::pair, to reduce typing and increase clarity. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D40615 llvm-svn: 319414
OpenPOWER on IntegriCloud