summaryrefslogtreecommitdiffstats
path: root/lldb/tools/lldb-test
Commit message (Collapse)AuthorAgeFilesLines
* SymbolVendor: Remove passthrough methodsPavel Labath2019-08-061-27/+25
| | | | | | | | | | After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to the symbol file directly -- in most cases that just means calling GetSymbolFile()->foo() instead of GetSymbolVendor()->foo(). llvm-svn: 368001
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-301-3/+8
| | | | | | | | | | | | | | | | | | 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] Increase testsuite packet-timeout 5secs -> 1minJan Kratochvil2019-07-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | rL357954 did increase `packet-timeout` 1sec -> 5secs. Which is IMO about the maximum timeout reasonable for regular use. But for testsuite I think the timeout should be higher as the testsuite runs in parallel and it can be run even on slow hosts and with other load (moreover if it runs on some slow arch). I have chosen 60 secs, that should be enough hopefully. Larger value could make debugging with hanging `lldb-server` annoying. This patch was based on this testsuite timeout: http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/546/steps/test/logs/stdio FAIL: test_connect (TestGDBRemoteClient.TestGDBRemoteClient) Test connecting to a remote gdb server ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py", line 13, in test_connect process = self.connect(target) File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py", line 480, in connect self.assertTrue(error.Success(), error.description) AssertionError: False is not True : failed to get reply to handshake packet Differential Revision: https://reviews.llvm.org/D65271 llvm-svn: 367234
* SymbolVendor: Move compile unit handling into the SymbolFile classPavel Labath2019-07-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SymbolFile classes are responsible for creating CompileUnit instances and they already need to have a notion of the id<->CompileUnit mapping (because of APIs like ParseCompileUnitAtIndex). However, the SymbolVendor has remained as the thing responsible for caching created units (which the SymbolFiles were calling via convoluted constructs like "m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)"). This patch moves the responsibility of caching the units into the SymbolFile class. It does this by moving the implementation of SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the equivalent SymbolFile functions. The SymbolVendor functions become just a passthrough much like the rest of SymbolVendor. The original implementations of SymbolFile::GetNumCompileUnits is moved to "CalculateNumCompileUnits", and are made protected, as the "Get" function is the external api of the class. SymbolFile::ParseCompileUnitAtIndex is made protected for the same reason. This is the first step in removing the SymbolVendor indirection, as proposed in <http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After removing all interesting logic from the SymbolVendor class, I'll proceed with removing the indirection itself. Reviewers: clayborg, jingham, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65089 llvm-svn: 366791
* Add convenience methods to convert LLDB to LLVM data structures.Jonas Devlieghere2019-07-111-1/+1
| | | | | | | | | | This patch adds two convenience methods named GetAsLLVM to the LLDB counterparts of the DWARF DataExtractor and the DWARF context. The DWARFContext, once created, is cached for future usage. Differential revision: https://reviews.llvm.org/D64535 llvm-svn: 365819
* [lldb] [test] Extend D55859 symbols.enable-external-lookup=false for more ↵Jan Kratochvil2019-06-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | testcases D55859 <https://reviews.llvm.org/D55859> has no effect for some of the testcases so this patch extends it even for (all?) other testcases known to me. LLDB was failing when LLDB prints errors reading system debug infos (`*-debuginfo.rpm`, DWZ-optimized) which should never happen as LLDB testcases should not be affected by system debug infos. `lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template` is using only SB API which does not expose `ModuleList` so I had to call `HandleCommand()` there. `lldb-test.cpp` could also use `HandleCommand` and then there would be no need for `ModuleListProperties::SetEnableExternalLookup()` but I think it is cleaner with API and not on based on text commands. Differential Revision: https://reviews.llvm.org/D63339 llvm-svn: 363567
* Fix lit tests on Windows related to CR+LFAdrian McCarthy2019-06-071-2/+2
| | | | | | | | | | | | | | | | | | | | | Problem discovered in the breakpoint lit test, but probably exists in others. lldb-test splits lines on LF. Input files that are CR+LF separated (as is common on Windows) then resulted in commands being sent to LLDB that ended in CR, which confused the command interpreter. This could be fixed at different levels: 1. Treat '\r' like a tab or space in the argument splitter. 2. Fix the line splitters (plural) in lldb-test. 3. Normalize the test files to LF only. If we did only 3, I'd expect similar problems to recur, so this patch does 1 and 2. I may also do 3 in a separate patch later, but that's tricky because I believe we have some input files that MUST use CR+LF. Differential Revision: https://reviews.llvm.org/D62759 llvm-svn: 362844
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-061-4/+7
| | | | | | | | | | | | | | | | | | | | | | | Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-102-4/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* [Platform] Remove Kalimba PlatformJonas Devlieghere2019-03-271-3/+0
| | | | | | | | | This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-213-5/+4
| | | | | | | | | | | | | | | | As per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html This commit implements option (3): > Go back to initializing the reproducer before the rest of the debugger. > The method wouldn't be instrumented and guarantee no other SB methods are > called or SB objects are constructed. The initialization then becomes part > of the replay. Differential revision: https://reviews.llvm.org/D58410 llvm-svn: 354631
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-195-20/+15
| | | | | | | | | | | | | | | | | 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-2/+1
| | | | | | | | | | | | | | 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] Remove the SymbolContext parameter from FindNamespace.Zachary Turner2019-01-141-2/+1
| | | | | | | | | | | Every callsite was passing an empty SymbolContext, so this parameter had no effect. Inside the DWARF implementation of this function, however, there was one codepath that checked members of the SymbolContext. Since no call-sites actually ever used this functionality, it was essentially dead code, so I've deleted this code path as well. llvm-svn: 351132
* Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath2019-01-112-23/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds the glue code necessary to integrate the SymbolFileBreakpad into the plugin system. Most of the methods are stubbed out. The only method implemented method is AddSymbols, which parses the PUBLIC "section" of the breakpad "object file", and fills out the Module's symtab. To enable testing this, I've made two additional changes: - dump Symtab from the SymbolVendor class. The symtab was already being dumped as a part of the object file dump, but that happened before symbol vendor kicked in, so it did not reflect any symbols added there. - add ability to explicitly specify the external symbol file in lldb-test (so that the object file could be linked with the breakpad symbol file). To make things simpler, I've changed lldb-test from consuming multiple inputs (and dumping their symbols) to having it just process a single file per invocation. This was not a problem since everyone was using it that way already. Reviewers: clayborg, zturner, lemo, markmentovai, amccarth Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56173 llvm-svn: 350924
* Implement ObjectFileELF::GetBaseAddressPavel Labath2019-01-101-0/+2
| | | | | | | | | Summary: The concept of a base address was already present in the implementation (it's needed for computing section load addresses properly), but it was never exposed through this function. This fixes that. llvm-svn: 350804
* Change lldb-test to use ParseAllDebugSymbols.Zachary Turner2019-01-091-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ParseDeclsForContext was originally created to serve the very specific case where the context is a function block. It was never intended to be used for arbitrary DeclContexts, however due to the generic name, the DWARF and PDB plugins implemented it in this way "just in case". Then, lldb-test came along and decided to use it in that way. Related to this, there are a set of functions in the SymbolFile class interface whose requirements and expectations are not documented. For example, if you call ParseCompileUnitFunctions, there's an inherent requirement that you create entries in the underlying clang AST for these functions as well as their signature types, because in order to create an lldb_private::Function object, you have to pass it a CompilerType for the parameter representing the signature. On the other hand, there is no similar requirement (either inherent or documented) if one were to call ParseDeclsForContext. Specifically, if one calls ParseDeclsForContext, and some variable declarations, types, and other things are added to the clang AST, is it necessary to create lldb::Variable, lldb::Type, etc objects representing them? Nobody knows. There is, however, an accidental requirement, because since all of the plugins implemented this just in case, lldb-test came along and used ParsedDeclsForContext, and then wrote check lines that depended on this. When I went to try and implemented the NativePDB reader, I did not adhere to this (in fact, from a layering perspective I went out of my way to avoid it), and as a result the existing DIA PDB tests don't work when the native PDB reader is enabled, because they expect that calling ParseDeclsForContext will modify the *module's* view of symbols, and not just the internal AST. All of this confusion, however, can be avoided if we simply stick to using ParseDeclsForContext for its original intended use case (blocks), and use a different function (ParseAllDebugSymbols) for its intended use case which is, unsuprisingly, to parse all the debug symbols (which is all lldb-test really wanted to do anyway). In the future, I would like to change ParseDeclsForContext to ParseDeclsForFunctionBlock, then delete all of the dead code inside that handles other types of DeclContexts (and probably even assert if the DeclContext is anything other than a block). A few PDB tests needed to be fixed up as a result of this, and this also exposed a couple of bugs in the DIA PDB reader (doesn't matter much since it should be going away soon, but worth mentioning) where the appropriate AST entries weren't being created always. Differential Revision: https://reviews.llvm.org/D56418 llvm-svn: 350764
* lldb-test ir-memory-map: Use IntervalMap::containsPavel Labath2018-12-271-25/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Simplify the code by using the contains implementation in IntervalMap. There is a slight change of behavior here: We now treat an allocation of size 0, as if it was size 1. This guarantees that the returned addresses will be unique, whereas previously we would allow the allocation function to return the same zero-sized region multiple times, as long as it is not null, and not in the middle of an existing interval (but the situation when we were placing an larger interval over a zero-sized one was not detected). I think this behavior makes more sense, as that is pretty much the same guarantee as offered by malloc (except that is permitted to also return nullptr). Reviewers: vsk Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D55761 llvm-svn: 350087
* ELF: Don't create sections for section header index 0Pavel Labath2018-12-181-0/+1
| | | | | | | | | | | | | | | | | | | Summary: The first section header does not define a real section. Instead it is used for various elf extensions. This patch skips creation of a section for index 0. This has one furtunate side-effect, in that it allows us to use the section header index as the Section ID (where 0 is also invalid). This way, we can get rid of a lot of spurious +1s in the ObjectFileELF code. Reviewers: clayborg, krytarowski, joerg, espindola Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D55757 llvm-svn: 349498
* lldb-test: Improve newline handlingPavel Labath2018-12-152-37/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously lldb-test's LinePrinter would output the indentation spaces even on completely empty lines. This is not nice, as trailing spaces get flagged as errors in some tools/editors, and it prevents FileCheck's CHECK-EMPTY from working. Equally annoying was the fact that the LinePrinter did not terminate it's output with a newline (instead it would leave the unterminated hanging indent from the last NewLine() command), which meant that the shell prompt following the lldb-test command came out wrong. This fixes both issues by changing how newlines are handled. NewLine(), which was ending the previous line ('\n') *and* begging the next line by printing the indent, is now "demoted" to just printing literal "\n". Instead, lines are now delimited via a helper Line object, which makes sure the line is indented and terminated in an RAII fashion. The typical usage would be: Printer.line() << "This text will be indented and terminated"; If one needs to do more work than it will fit into a single statement, one can also assign the result of the line() function to a local variable. The line will then be terminated when that object goes out of scope. Reviewers: zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D55597 llvm-svn: 349269
* ELF: more section creation cleanupPavel Labath2018-12-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch attempts to move as much code as possible out of the CreateSections function to make room for future improvements there. Some of this may be slightly over-engineered (VMAddressProvider), but I wanted to keep the logic of this function very simple, because once I start taking segment headers into acount (as discussed in D55356), the function is going to grow significantly. While in there, I also added tests for various bits of functionality. This should be NFC, except that I changed the order of hac^H^Heuristicks for determining section type slightly. Previously, name-based deduction (.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB -> symtab) one. In fact we would assert if we ran into a .text section with type SHT_SYMTAB. Though unlikely to matter in practice, this order seemed wrong to me, so I have inverted it. Reviewers: clayborg, krytarowski, espindola Subscribers: emaste, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D55706 llvm-svn: 349268
* ELF: Clean up section type computationPavel Labath2018-12-121-0/+1
| | | | | | | | | | | | | Move code into a separate function, and replace the if-else chain with llvm::StringSwitch. A slight behavioral change is that now I use the section flags (SHF_TLS) instead of the section name to set the thread-specific property. There is no explanation in the original commit introducing this (r153537) as to why that was done this way, but the new behavior should be more correct. llvm-svn: 348936
* lldb-test: Add ability to dump subsectionsPavel Labath2018-12-121-20/+32
| | | | | | | | Previously, lldb-test would only print top-level sections. However, in lldb, sections can contain other sections. This teaches lldb-test to print nested sections too. llvm-svn: 348924
* Re-commit "Introduce ObjectFileBreakpad"Pavel Labath2018-12-102-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r348592, which was reverted due to a failing test on macos. The issue was that I was passing a null pointer for the "CreateMemoryInstance" callback when registering ObjectFileBreakpad, which caused crashes when attemping to load modules from memory. The correct thing to do is to pass a callback which always returns a null pointer (as breakpad files are never loaded in inferior memory). It turns out that there is only one test which exercises this code path, and it's mac-only, so I've create a new test which should run everywhere (except windows, as one cannot delete an executable which is being run). Unfortunately, this test still fails on linux for other reasons, but at least it gives us something to aim for. The original commit message was: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348773
* Revert "Introduce ObjectFileBreakpad"Shafik Yaghmour2018-12-072-16/+0
| | | | | | | | This reverts commit 5e056e624cc57bb22a4c29a70b522783c6242293. Reverting because this lldb cmake bot: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/ llvm-svn: 348629
* Introduce ObjectFileBreakpadPavel Labath2018-12-072-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348592
* [pecoff] Implement ObjectFilePECOFF::GetDependedModules()Aaron Smith2018-12-061-4/+20
| | | | | | | | | | | | | | | | | | Summary: This parses entries in pecoff import tables for imported DLLs and is intended as the first step to allow LLDB to load a PE's shared modules when creating a target on the LLDB console. Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith Reviewed By: labath, asmith Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor Differential Revision: https://reviews.llvm.org/D53094 llvm-svn: 348527
* [Reproducers] Change how reproducers are initialized.Jonas Devlieghere2018-12-033-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the way the reproducer is initialized. Rather than making changes at run time we now do everything at initialization time. To make this happen we had to introduce initializer options and their SB variant. This allows us to tell the initializer that we're running in reproducer capture/replay mode. Because of this change we also had to alter our testing strategy. We cannot reinitialize LLDB when using the dotest infrastructure. Instead we use lit and invoke two instances of the driver. Another consequence is that we can no longer enable capture or replay through commands. This was bound to go away form the beginning, but I had something in mind where you could enable/disable specific providers. However this seems like it adds very little value right now so the corresponding commands were removed. Finally this change also means you now have to control this through the driver, for which I replaced --reproducer with --capture and --replay to differentiate between the two modes. Differential revision: https://reviews.llvm.org/D55038 llvm-svn: 348152
* Remove OCaml debugger pluginJonas Devlieghere2018-11-051-6/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the OCaml debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54060 llvm-svn: 346159
* Remove Java debugger pluginJonas Devlieghere2018-11-051-9/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Java debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54059 llvm-svn: 346158
* Remove Go debugger pluginJonas Devlieghere2018-11-051-11/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Go debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54057 llvm-svn: 346157
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-5/+5
| | | | | | | | | 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
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* [NFC] Turn "load dependent files" boolean into an enumJonas Devlieghere2018-09-201-4/+3
| | | | | | | | | | | | | | This is an NFC commit to refactor the "load dependent files" parameter from a boolean to an enum value. We want to be able to specify a default, in which case we decide whether or not to load the dependent files based on whether the target is an executable or not (i.e. a dylib). This is a dependency for D51934. Differential revision: https://reviews.llvm.org/D51859 llvm-svn: 342633
* [PDB] Restore AST from PDB symbolsAleksandr Urakov2018-09-101-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PDB] Resolve a symbol context block info correctlyAleksandr Urakov2018-08-291-0/+48
| | | | | | | | | | | | | | | | | | | Summary: This patch allows to resolve a symbol context block info even if a function info was not requested. Also it adds the correct resolving of nested blocks (the previous implementation used function blocks instead of them). Reviewers: zturner, asmith, labath Reviewed By: asmith Subscribers: lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D51104 llvm-svn: 340901
* Add a test for reading lld-generated build-idsPavel Labath2018-06-291-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This test makes sure we are able to read the shorter build-ids which are generated by lld. To make this work, I've extended lldb-test to print the UUID of the loaded object file. I've renamed the lldb-test subcommand from "module-sections" to "object-file" to reflect the fact it prints more than just the sections. I've also added the module Architecture to the output, so we could avoid printing the entire symbol file information just to get the ArchSpec details in the lc_version_min test (which was also the only test in it's folder not using the module-sections command). Reviewers: aprantl, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48646 llvm-svn: 335967
* Retrieve a function PDB symbol correctly from nested blocksPavel Labath2018-06-281-24/+58
| | | | | | | | | | | | | | | | | | | Summary: This patch fixes a problem with retrieving a function symbol by an address in a nested block. In the current implementation of ResolveSymbolContext function it retrieves a symbol with PDB_SymType::None and then checks if found symbol's tag equals to PDB_SymType::Function. So, if nested block's symbol was found, ResolveSymbolContext does not resolve a function. Reviewers: asmith, labath, zturner Reviewed By: asmith, labath Differential Revision: https://reviews.llvm.org/D47939 Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com> llvm-svn: 335822
* [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 build error introduced in r334498Pavel Labath2018-06-121-2/+2
| | | | | | | | | | Some gcc versions (circa 4.9) do not accept initializing Expected objects containing a reference to a function from a function. Change the Expected object to contain function pointers to work around this. llvm-svn: 334501
* lldb-test symbols: Add -file argument and the ability to dump global ↵Pavel Labath2018-06-121-73/+101
| | | | | | | | | | | | | | | variables in a file The motivation for this is to be able to Dwarf index ability to look up variables within a given compilation unit. It also fits in with the patch in progress at D47939, which will add the ability to look up funtions using file+line pairs. The verification of which lldb-test options can be used together was getting a bit unwieldy, so I moved the logic out into a separate function. llvm-svn: 334498
* PDB support of function-level linking and splitted functionsAaron Smith2018-06-081-17/+94
| | | | | | | | | | | | | | | | | | | Summary: The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature. SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0). To fix the problem this patch renews the sequence on each address gap. Reviewers: asmith, zturner Reviewed By: asmith Subscribers: aleksandr.urakov, labath, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D47708 llvm-svn: 334260
* [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commandsVedant Kumar2018-06-041-37/+54
| | | | | | | | | | | | | | | | Change the syntax of the malloc and free commands in lldb-test's ir-memory-map subcommand to: <malloc> ::= <label> = malloc <size> <alignment> <free> ::= free <label> This should make it easier to read and extend tests in the future, e.g to test IRMemoryMap::WriteMemory or double-free behavior. Differential Revision: https://reviews.llvm.org/D47646 llvm-svn: 333930
* [IRMemoryMap] Test interleaved Mallocs and FreesVedant Kumar2018-05-311-3/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new command to the ir-memory-map tester: free <allocation-index> The argument to free is an index which identifies which live allocation to free. Index 0 identifies the first live allocation in the address space, index 1 identifies the second, etc. where the allocations are sorted in increasing order. For illustrative purposes, assume malloc returns monotonically increasing addresses. Here are some examples of how free would work: Example 1 --------- malloc 16 1 malloc 32 1 free 1 //< Free the 32-byte allocation. free 0 //< Next, free the 16-byte allocation. Example 2 --------- malloc 16 1 malloc 32 1 free 0 //< Free the 16-byte allocation. free 0 //< Next, free the 32-byte allocation. llvm-svn: 333700
* [lldb-test] Make logging available to all subcommandsVedant Kumar2018-05-311-0/+3
| | | | llvm-svn: 333699
* [IRMemoryMap] Test host-side allocationsVedant Kumar2018-05-311-3/+9
| | | | | | | | r333583 introduced testing for IRMemoryMap's process-side allocations (eAllocationPolicyProcessOnly). This adds support for the host-side variety (eAllocationPolicyHostOnly). llvm-svn: 333698
* Remove append parameter to FindGlobalVariablesPavel Labath2018-05-311-5/+3
| | | | | | | | | | | | | | | | | | | 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
* [lldb-test] ir-memory-map: Avoid accessing a bad iteratorVedant Kumar2018-05-301-10/+8
| | | | | | | Do not access Probe.start() when Probe is at the end of the interval map. llvm-svn: 333585
* [lldb-test] Add a testing harness for the JIT's IRMemoryMapVedant Kumar2018-05-301-19/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
* Move ObjectFile initialization out of SystemInitializerCommonPavel Labath2018-05-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | Summary: For lldb-server, it is sufficient to parse only the native object file format for its target OS (no other file can be loaded into a running process). This moves the object file initialization code into specific initializer classes: lldb-test and liblldb get all object files; lldb-server gets only one of them. For this to work, I've needed to create a special SystemInitializer for use in lldb-server, instead of it calling directly into the common one. This reduces the size of lldb-server by about 2%, which is not earth-shattering, but it's an easy win, and it helps. Reviewers: zturner, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D47250 llvm-svn: 333182
OpenPOWER on IntegriCloud