summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression
Commit message (Collapse)AuthorAgeFilesLines
* Fix a buffer-size bug when the first DW_OP_piece is undefinedAdrian Prantl2020-02-191-1/+5
| | | | | | | | | | | | | | and document the shortcomings of LLDB's partially defined DW_OP_piece handling. This would manifest as "DW_OP_piece for offset foo but top of stack is of size bar". rdar://problem/46262998 Differential Revision: https://reviews.llvm.org/D72880 (cherry picked from commit f55ab6f90b7317a6bb85303a6102702bdae1199e)
* Add testing for DW_OP_piece and fix a bug with small Scalar values.Adrian Prantl2020-02-191-4/+12
| | | | | | | | | | | | By switching to Scalars that are backed by explicitly-sized APInts we can avoid a bug that increases the buffer reserved for a small piece to the next-largest host integer type. This manifests as "DW_OP_piece for offset foo but top of stack is of size bar". Differential Revision: https://reviews.llvm.org/D72879 (cherry picked from commit 7b0d58e339b271e3b1d9dc14b781b57fa0262e3a)
* [lldb] Don't defend against internal LLVM errors in IRInterpreterRaphael Isemann2020-01-141-125/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Whenever we cast an LLVM instruction to one of its subclasses, we do a double check if the RTTI enum value actually allows us to cast the class. I don't see a way this can ever happen as even when LLVM's RTTI system has some corrupt internal state (which we probably should not test in the first place) we just reuse LLVM RTTI to do the second check. This also means that if we ever make an actual programming error in this function (e.g., have a enum value and then cast it to a different subclass), we just silently fall back to the JIT in our tests. We also can't test this code in any reasonable way. This removes the checks and uses `llvm::cast` instead which will raise a fatal error when casting fails. Reviewers: labath, mib Reviewed By: labath Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72596
* [lldb][NFC] Use range-based for loops in IRInterpreterRaphael Isemann2020-01-131-16/+12
|
* Add missing nullptr checks.Adrian Prantl2020-01-102-2/+5
| | | | | | | | | | GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses. Inspired by rdar://problem/58317195 Differential Revision: https://reviews.llvm.org/D72413
* [lldb/DWARF] Fix mixed v4+v5 location listsPavel Labath2020-01-091-31/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: Our code was expecting that a single (symbol) file contains only one kind of location lists. This is not correct (on non-apple platforms, at least) as a file can compile units with different dwarf versions. This patch moves the deteremination of location list flavour down to the compile unit level, fixing this problem. I have also tried to rougly align the code with the llvm DWARFUnit. Fully matching the API is not possible because of how lldb's DWARFExpression lives separately from the rest of the DWARF code, but this is at least a step in the right direction. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71751
* [UserExpression] Clean up `return` after `else`.Davide Italiano2020-01-031-4/+3
|
* [lldb] Fix ARM32 inferior callsJan Kratochvil2019-12-212-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
* [lldb/DWARF] Switch to llvm location list parserPavel Labath2019-12-091-261/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch deletes the lldb location list parser and teaches the DWARFExpression class to use the parser in llvm instead. I have centralized all the places doing the parsing into a single GetLocationExpression function. In theory the the actual location list parsing should be covered by llvm tests, and this glue code by our existing location list tests, but since we don't have that many location list tests, I've tried to extend the coverage a bit by adding some explicit dwarf5 loclist handling and a test of the dumping code. For DWARF4 location lists this should be NFC (modulo small differences in error handling which should only show up on invalid inputs). In case of DWARF5, this fixes various missing bits of functionality, most notably, the lack of support for DW_LLE_offset_pair. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits, dblaikie Tags: #lldb Differential Revision: https://reviews.llvm.org/D71003
* [lldb] Improve/fix base address selection in location listsPavel Labath2019-12-091-51/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Lldb support base address selection entries in location lists was broken for a long time. This wasn't noticed until llvm started producing these kinds of entries more frequently with r374600. In r374769, I made a quick patch which added sufficient support for them to get the test suite to pass. However, I did not fully understand how this code operates, and so the fix was not complete. Specifically, what was lacking was the ability to handle modules which were not loaded at their preferred load address (for instance, due to ASLR). Now that I better understand how this code works, I've come to the conclusion that the current setup does not provide enough information to correctly process these entries. In the current setup the location lists were parameterized by two addresses: - the distance of the function start from the start of the compile unit. The purpose of this was to make the location ranges relative to the start of the function. - the actual address where the function was loaded at. With this the function-start-relative ranges can be translated to actual memory locations. The reason for the two values, instead of just one (the load bias) is (I think) MachO, where the debug info in the object files will appear to be relative to the address zero, but the actual code it refers to can be moved and reordered by the linker. This means that the location lists need to be "linked" to reflect the locations in the actual linked file. These two bits of information were enough to correctly process location lists which do not contain base address selection entries (and so all entries are relative to the CU base). However, they don't work with them because, in theory two base address can be completely unrelated (as can happen for instace with hot/cold function splitting, where the linker can reorder the two pars arbitrarily). To fix that, I split the first parameter into two: - the compile unit base address - the function start address, as is known in the object file The new algorithm becomes: - the location lists are processed as they were meant to be processed. The CU base address is used as the initial base address value. Base address selection entries can set a new base. - the difference between the "file" and "load" function start addresses is used to compute the load bias. This value is added to the final ranges to get the actual memory location. This algorithm is correct for non-MachO debug info, as there the location lists correctly describe the code in the final executable, and the dynamic linker can just move the entire module, not pieces of it. It will also be correct for MachO if the static linker preserves relative positions of the various parts of the location lists -- I don't know whether it actually does that, but judging by the lack of base address selection support in dsymutil and lldb, this isn't something that has come up in the past. I add a test case which simulates the ASLR scenario and demonstrates that base address selection entries now work correctly here. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70532
* [lldb] Migrate VMRange::Dump to raw_ostreamRaphael Isemann2019-12-061-1/+1
|
* [lldb/IRExecutionUnit] Stop searching based on demangled namesPavel Labath2019-12-061-2/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This was causing problems on linux, where we'd end up calling the deleting destructor instead of a regular one (because they have the same demangled name), making a lot of mischief in the process. The only place where this was necessary (according to the test suite, at least) was to call a base structor instead of a complete one, but this is now handled in a more targeted fashion. TestCallOverriddenMethod is now re-enabled as it now passes reliably. Reviewers: teemperor, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70722
* [lldb][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-051-2/+3
| | | | | | | | | | | | | | | | | | | | | | them take raw_ostream Summary: Yet another step on the long road towards getting rid of lldb's Stream class. We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs. I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71052
* [lldb] remove unsigned Stream::operator<< overloadsPavel Labath2019-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I recently re-discovered that the unsinged stream operators of the lldb_private::Stream class have a surprising behavior in that they print the number in hex. This is all the more confusing because the "signed" versions of those operators behave normally. Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream wrapper, I think we should delete most of our formatting capabilities and just delegate to that. This patch tests the water by just deleting the operators with the most surprising behavior. Most of the code using these operators was printing user_id_t values. It wasn't fully consistent about prefixing them with "0x", but I've tried to consistenly print it without that prefix, to make it more obviously different from pointer values. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70241
* [DWARF] Handle call sites with indirect call targetsVedant Kumar2019-11-221-6/+6
| | | | | | | | | | Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach DWARFExpression how to evaluate entry values in cases where the current activation was created by an indirect call. rdar://57094085 Differential Revision: https://reviews.llvm.org/D70100
* [lldb] Add logging to IRExecutionUnit::GetStaticInitializersRaphael Isemann2019-11-191-6/+21
|
* [lldb][NFC] Early exit in IRExecutionUnit::GetStaticInitializersRaphael Isemann2019-11-191-24/+28
|
* [LLDB] Cleanup the DataEncoder utility. (NFC)Jonas Devlieghere2019-11-131-3/+3
| | | | | This commit removes unused methods from the DataEncoder class and cleans up the API by making all the internal methods private.
* [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variableRaphael Isemann2019-11-125-23/+23
| | | | | | | | | | | | | | | | Summary: swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI with a static ID variable instead of a centralised enum we can drop that patch. Reviewers: labath, davide Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D70070
* [lldb][NFC] Make LLVMUserExpression::DoExecute return earlyRaphael Isemann2019-10-291-144/+142
| | | | The giant if-else isn't conforming to LLVM code style.
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-171-2/+0
| | | | | | | | | | | | 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
* DWARFExpression: Fix/add support for (v4) debug_loc base address selection ↵Pavel Labath2019-10-141-0/+18
| | | | | | | | | | | | | | | | | | | | entries The DWARFExpression is parsing the location lists in about five places. Of those, only one actually had proper support for base address selection entries. Since r374600, llvm has started to produce location expressions with base address selection entries more aggresively, which caused some tests to fail. This patch adds support for these entries to the places which had it missing, fixing the failing tests. It also adds a targeted test for the two of the three fixes, which should continue testing this functionality even if the llvm output changes. I am not aware of a way to write a targeted test for the third fix (DWARFExpression::Evaluate). llvm-svn: 374769
* [lldb][NFC] Use unique_ptr in DiagnosticManager to express ownershipRaphael Isemann2019-10-101-1/+1
| | | | llvm-svn: 374289
* remove a smattering of isolated, unnecessary uses of FILE*Lawrence D'Anna2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | Summary: There a a few call sites that use FILE* which are easy to fix without disrupting anything else. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68444 llvm-svn: 374239
* Remove the is_mangled flag from Mangled and SymbolAdrian Prantl2019-10-091-2/+2
| | | | | | | | | | | | | | | Testing whether a name is mangled or not is extremely cheap and can be done by looking at the first two characters. Mangled knows how to do it. On the flip side, many call sites that currently pass in an is_mangled determination do not know how to correctly do it (for example, they leave out Swift mangling prefixes). This patch removes this entry point and just forced Mangled to determine the mangledness of a string itself. Differential Revision: https://reviews.llvm.org/D68674 llvm-svn: 374180
* Use llvm for dumping DWARF expressionsPavel Labath2019-09-301-407/+4
| | | | | | | | | | | | | | | Summary: It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo structs (which is what is needed to turn dwarf register numbers into strings). Reviewers: JDevlieghere, aprantl, jasonmolenda Subscribers: tatyana-krasnukha, lldb-commits Differential Revision: https://reviews.llvm.org/D67966 llvm-svn: 373208
* remove File::SetStream(), make new files instead.Lawrence D'Anna2019-09-271-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes File::SetStream() and File::SetDescriptor(), and replaces most direct uses of File with pointers to File. Instead of calling SetStream() on a file, we make a new file and replace it. My ultimate goal here is to introduce a new API class SBFile, which has full support for python io.IOStream file objects. These can redirect read() and write() to python code, so lldb::Files will need a way to dispatch those methods. Additionally it will need some form of sharing and assigning files, as a SBFile will be passed in and assigned to the main IO streams of the debugger. In my prototype patch queue, I make File itself copyable and add a secondary class FileOps to manage the sharing and dispatch. In that case SBFile was a unique_ptr<File>. (here: https://github.com/smoofra/llvm-project/tree/files) However in review, Pavel Labath suggested that it be shared_ptr instead. (here: https://reviews.llvm.org/D67793) In order for SBFile to use shared_ptr<File>, everything else should as well. If this patch is accepted, I will make SBFile use a shared_ptr I will remove FileOps from future patches and use subclasses of File instead. Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67891 llvm-svn: 373090
* Convert FileSystem::Open() to return Expected<FileUP>Lawrence D'Anna2019-09-261-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
* [lldb][NFC] Remove CompletionRequest::GetCursorArgument and ↵Raphael Isemann2019-09-251-2/+2
| | | | | | | | | | GetRawLineUntilCursor They both return the same result as another function (GetCursorArgumentPrefix and GetRawLine). They were only added because the old API allowed to look (in theory) behind the cursor position which is no longer possible. llvm-svn: 372861
* [DWARF] Evaluate DW_OP_entry_valueVedant Kumar2019-09-111-0/+261
| | | | | | | | | | | | Add support for evaluating DW_OP_entry_value. This involves parsing DW_TAG_call_site_parameter and wiring the information through to the expression evaluator. rdar://54496008 Differential Revision: https://reviews.llvm.org/D67376 llvm-svn: 371668
* Implement DW_OP_convertAdrian Prantl2019-09-101-0/+77
| | | | | | | | | | | | | | | | | | | | | | This patch adds basic support for DW_OP_convert[1] for integer types. Recent versions of LLVM's optimizer may insert this opcode into DWARF expressions. DW_OP_convert is effectively a type cast operation that takes a reference to a base type DIE (or zero) and then casts the value at the top of the DWARF stack to that type. Internally this works by changing the bit size of the APInt that is used as backing storage for LLDB's DWARF stack. I managed to write a unit test for this by implementing a mock YAML object file / module that takes debug info sections in yaml2obj format. [1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1 <rdar://problem/48167864> Differential Revision: https://reviews.llvm.org/D67369 llvm-svn: 371532
* [Expression] Remove unused header from LLVMUserExpressionAlex Langford2019-09-091-1/+0
| | | | llvm-svn: 371472
* [lldb][NFC] Remove Args::StripSpacesRaphael Isemann2019-09-061-1/+1
| | | | | | This just reimplemented llvm::StringRef::[r/l]trim(). llvm-svn: 371181
* [lldb][NFC] Move Clang-specific flags to ClangUserExpressionRaphael Isemann2019-08-301-3/+1
| | | | | | | | | LLVMUserExpression doesn't use these variables and they are all specific to Clang. Also removes m_const_object as this was actually never used by anyone (and Clang didn't report it as we assigned it in the constructor which seems to count as use). llvm-svn: 370440
* Remove DWARFExpression::LocationListSizePavel Labath2019-08-291-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The only reason for this function's existance is so that we could pass the correct size into the DWARFExpression constructor. However, there is no harm in passing the entire data extractor into the DWARFExpression, since the same code is performing the size determination as well as the subsequent parse. So, if we get malformed input or there's a bug in the parser, we'd compute the wrong size anyway. Additionally, reducing the number of entry points into the location list parsing machinery makes it easier to switch the llvm debug_loc(lists) parsers. While inside, I added a couple of tests for invalid location list handling. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D66789 llvm-svn: 370373
* Revert "[lldb] Move redundant persistent variable counter to ↵Adrian Prantl2019-08-271-0/+10
| | | | | | | | | | | | ClangPersistentVariables" This reverts commit r367842 since it wasn't quite as NFC as advertised and broke Swift support. See https://reviews.llvm.org/D46083 for the rationale behind the original functionality. rdar://problem/54619322 llvm-svn: 370126
* DWARFExpression: Simplify class interfacePavel Labath2019-08-271-27/+15
| | | | | | | | | | | | | | | | | Summary: The DWARFExpression methods have a lot of arguments. This removes two of them by removing the ability to slice the expression via two offset+size parameters. This is a functionality that it is not always needed, and when it is, we already have a different handy way of slicing a data extractor which we can use instead. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66745 llvm-svn: 370027
* [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and ↵Raphael Isemann2019-08-221-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
* [lldb][NFC] Refactor remaining completion logic to use CompletionRequestsRaphael Isemann2019-08-151-19/+20
| | | | | | | | | | | | | | | | | | | | This patch moves the remaining completion functions from the old completion API (that used several variables) to just passing a single CompletionRequest. This is for the most part a simple change as we just replace the old arguments with a single CompletionRequest argument. There are a few places where I had to create new CompletionRequests in the called functions as CompletionRequests itself are immutable and don't expose their internal match list anymore. This means that if a function wanted to change the CompletionRequest or directly access the result list, we need to work around this by creating a new CompletionRequest and a temporary match/description list. Preparation work for rdar://53769355 llvm-svn: 369000
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | 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
* [CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.Davide Italiano2019-08-121-2/+2
| | | | llvm-svn: 368620
* [Symbol] GetTypeBitAlign() should return None in case of failure.Davide Italiano2019-08-121-8/+14
| | | | | | | | | | | | | | | | Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
* [lldb] Remove undocumented return value from DiagnosticManager::PutStringRaphael Isemann2019-08-121-4/+3
| | | | | | | | | | | The returned value is currently unused. It also seems to imply that it somehow represents 'printf-style' the number of characters/bytes written to some output stream (which is incorrect, as we only know the actual size of the written message when we have rendered it, e.g. via GetString and DiagnosticManagers have no associated output stream). llvm-svn: 368577
* [Materializer] Remove wrong SetSizeAndAlignmentFromType().Davide Italiano2019-08-081-14/+0
| | | | | | | | | | | | This function is unused. It's also wrong, because it computes the size and the alignment of the type without asking the runtime, so it doesn't work for any language that has one (e.g. swift). One could consider re-implementing this passing an execution scope context, and modifying GetTypeBitAlign() to do the right thing, but given there are no uses, it's not really useful. llvm-svn: 368249
* Detect HAVE_SYS_TYPES_H in lldbHaibo Huang2019-08-072-0/+4
| | | | | | | | | | | | | | | | Summary: After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in Platform.h, or anywhere else in lldb. This change fixes that. Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65822 llvm-svn: 368125
* [lldb] Move redundant persistent variable counter to ClangPersistentVariablesRaphael Isemann2019-08-051-10/+0
| | | | | | | | | | | | | | | | | Currently Target::m_next_persistent_variable_index is counting up for our persistent variables ($0, $1, ...) but we also have a unused counter that is supposed to do this in ClangPersistentVariables but that stays always at 0 (because we currently increase the target counter when we should increase that unused counter). This patch removes the counter in Target and lets the documented counter in ClangPersistentVariables do the variable counting. Patch *should* be NFC, but it might unexpectedly bring LLDB to new code paths that could contain exciting new bugs to fix. llvm-svn: 367842
* SymbolVendor: Introduce Module::GetSymbolFilePavel Labath2019-08-021-5/+1
| | | | | | | | | | | | | | | | | | | | | 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
* [CompletionRequest] Remove unimplemented members.Jonas Devlieghere2019-07-311-3/+1
| | | | | | | | | | Completion requests have two fields that are essentially unimplemented: `m_match_start_point` and `m_max_return_elements`. This would've been okay, if it wasn't for the fact that this caused a bunch of useless parameters to be passed around. Occasionally there would be a comment or assert saying that they are not supported. This patch removes them. llvm-svn: 367385
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-301-7/+5
| | | | | | | | | | | | | | | | | | 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
* [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
OpenPOWER on IntegriCloud