summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename Target::GetSharedModule to Target::GetOrCreateModule.Jason Molenda2019-04-082-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a flag to control whether the ModulesDidLoad notification is called when a module is added. If the notifications are disabled, the caller must call ModulesDidLoad after adding all the new modules, but postponing this notification until they're all batched up can allow for better efficiency than notifying one-by-one. Change the name of the ModuleList notifier functions that a subclass can implement to start with 'Notify' to make it clear what they are. Add a NotifyModulesRemoved. Add header documentation for the changed/updated methods. Added defaulted-value 'notify' argument to ModuleList Append, AppendIfNeeded, and Remove because callers working with a local ModuleList don't have an obvious idea of what notify means in this context. When the ModuleList is a part of the Target class, the notify behavior matters. DynamicLoaderDarwin has been updated so that libraries being added/removed are correctly batched up before notifications are sent. Added the TestModuleLoadedNotifys.py test to run on Darwin to test this. <rdar://problem/48293064> Differential Revision: https://reviews.llvm.org/D60172 llvm-svn: 357955
* [CMake] Move link dependencies where they are used.Jonas Devlieghere2019-03-291-0/+4
| | | | | | | | | The utility library shouldn't depend on curses, libedit or python. Move curses to core, libedit to host and python to the python plugin. Differential revision: https://reviews.llvm.org/D59970 llvm-svn: 357287
* Use the multi-lockable form of std::lock for operator=Jim Ingham2019-03-291-19/+6
| | | | | | | | | | | For = operators for lists that have mutexes, we were either just taking the locks sequentially or hand-rolling a trick to try to avoid lock inversion. Use the std::lock mechanism for this instead. Differential Revision: https://reviews.llvm.org/D59957 llvm-svn: 357276
* Fix a "memset clearing an object of non-trivial type" warning in ↵Pavel Labath2019-03-191-8/+1
| | | | | | | | | | | | | | | | EmulateInstruction This is a new warning which started appearing as of gcc-8. The Opcode class has a non-trivial constructor, so the idea of the warning is that code should use that to initialize the object instead of using memset (which can perturb class invariants set up by the constructor). In this case, the Opcode default constructor was already clearing the object's fields so we can just drop the memset call. While I'm touching the EmulateInstruction constructor, I also move the initialization of other members into the class declaration. llvm-svn: 356459
* Reinitialize UnwindTable when the SymbolFile changesPavel Labath2019-03-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory step to enable adding of unwind plans by symbol file plugins. Although at the surface it seems that currently symbol files have nothing to do with unwinding, this isn't entirely correct even now. The mere act of adding a symbol file can have the effect of making more sections (typically .debug_frame) available to the unwinding machinery, so that it can have more unwind strategies to choose from. Up until now, we've had a bug, which went largely unnoticed, where unwind info in the manually added symbols files (target symbols add) was being ignored during unwinding. Reinitializing the UnwindTable fixes that bug too. Reviewers: clayborg, jasonmolenda, alexshap Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58347 llvm-svn: 356361
* Quiet command regex instructions during batch executionDave Lee2019-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Within .lldbinit, regex commands can be structured as a list of substitutions over multiple lines. It's possible that this is uninentional, but it works and has benefits. For example: command regex <command-name> s/pat1/repl1/ s/pat2/repl2/ ... I use this form of `command regex` in my `~/.lldbinit`, because it makes it clearer to write and read compared to a single line definition, because multiline substitutions don't need to be quoted, and are broken up one per line. However, multiline definitions result in usage instructions being printed for each use. The result is that every time I run `lldb`, I get a dozen or more lines of noise. With this change, the instructions are only printed when `command regex` is invoked interactively, or from a terminal, neither of which are true when lldb is sourcing `~/.lldbinit`. Reviewers: clayborg, jingham Reviewed By: clayborg Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits Differential Revision: https://reviews.llvm.org/D48752 llvm-svn: 355793
* Pass ConstString by value (NFC)Adrian Prantl2019-03-0617-131/+131
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* [Reproducers] Capture and replay interpreter commands.Jonas Devlieghere2019-03-022-12/+26
| | | | | | | | | | | | | | | | | This patch adds the necessary logic to capture and replay commands entered into the command interpreter. A DataRecorder shadows the input and writes its data to a know file. During replay this file is used as the command interpreter's input. It's possible to the command interpreter more than once, with a different input source. We support this scenario by using multiple buffers. The synchronization for this takes place at the SB layer, where we create a new recorder every time the debugger input is changed. During replay we use the corresponding buffer as input. Differential revision: https://reviews.llvm.org/D58564 llvm-svn: 355249
* Remove unnecessary demangling operation (NFC)Adrian Prantl2019-02-271-7/+5
| | | | | | | | | | | | This extra call to the demangler doesn't affect the performance of C++ because the result is being cached anyway; but I'm working on a patch to the Swift branch that uses extra contextual information to provide a more accurate demangling result. In that case this call would be extra and unnecessary work. Differential Revision: https://reviews.llvm.org/D58720 llvm-svn: 355042
* Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cppZachary Turner2019-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Given that we have a target named Symbols, one wonders why a file named Symbols.cpp is not in this target. To be clear, the functions exposed from this file are really focused on *locating* a symbol file on a given host, which is where the ambiguity comes in. However, it makes more sense conceptually to be in the Symbols target. While some of the specific places to search for symbol files might change depending on the Host, this is not inherently true in the same way that, for example, "accessing the file system" or "starting threads" is fundamentally dependent on the Host. PDBs, for example, recently became a reality on non-Windows platforms, and it's theoretically possible that DSYMs could become a thing on non MacOSX platforms (maybe in a remote debugging scenario). Other types of symbol files, such as DWO, DWP, etc have never been tied to any Host platform anyway. After this patch, there is only one remaining dependency from Host to Target. Differential Revision: https://reviews.llvm.org/D58730 llvm-svn: 355032
* Merge target triple into module triple when constructing module from memoryAlex Langford2019-02-201-0/+4
| | | | | | | | | | | | | | | | | | | Summary: While debugging an android process remotely from a windows machine, I noticed that the modules constructed from an object file in memory only had information about the architecture. Without knowledge of the OS or environment, expression evaluation sometimes leads to incorrectly generated code or a debugger crash. While we cannot know for certain what triple a module constructed from an in-memory object file will have, we can use the triple from the target to try and fill in the missing details. Reviewers: clayborg, zturner, JDevlieghere, compnerd, aprantl, labath Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58405 llvm-svn: 354526
* [gui] Simplify SourceFileWindowDelegate::WindowDelegateDrawPavel Labath2019-02-191-5/+2
| | | | | | | | | instead of printf-ing into a buffer, and them using that buffer as a format string, simply use the appropriate indirect format string. This also fixes a -Wformat-truncation warning with gcc. llvm-svn: 354307
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-137-98/+98
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-121-4/+4
| | | | | | | | This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
* Some cleanup after moving to std::make_sharedJonas Devlieghere2019-02-111-16/+9
| | | | | | Addresses Tatyana Krasnukha's feedback from D57990. llvm-svn: 353768
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-113-17/+21
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Simplify ObjectFile::GetUUIDPavel Labath2019-02-111-1/+1
| | | | | | | | | instead of returning the UUID through by-ref argument and a boolean value indicating success, we can just return it directly. Since the UUID class already has an invalid state, it can be used to denote the failure without the additional bool. llvm-svn: 353714
* SymbolFileBreakpad: Add line table supportPavel Labath2019-02-071-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch teaches SymbolFileBreakpad to parse the line information in breakpad files and present it to lldb. The trickiest question here was what kind of "compile units" to present to lldb, as there really isn't enough information in breakpad files to correctly reconstruct those. A couple of options were considered - have the entire file be one compile unit - have one compile unit for each FILE record - have one compile unit for each FUNC record The main drawback of the first approach is that all of the files would be considered "headers" by lldb, and so they wouldn't be searched if target.inline-breakpoint-strategy=never. The single compile unit would also be huge, and there isn't a good way to name it. The second approach will create mostly correct compile units for cpp files, but it will still be wrong for headers. However, the biggest drawback here seemed to be the fact that this can cause a compile unit to change mid-function (for example when a function from another file is inlined or another file is #included into a function). While I don't know of any specific thing that would break in this case, it does sound like a thing that we should avoid. In the end, we chose the third option, as it didn't seem to have any major disadvantages, though it was not ideal either. One disadvantage here is that this generates a large number of compile units, and there is still a question on how to name it. We chose to simply name it after the first line record in that function. This should be correct 99.99% of the time, though it can produce somewhat strange results if the very first line record comes from an #included file. Reviewers: clayborg, zturner, lemo, markmentovai Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56595 llvm-svn: 353404
* Make Type::GetByteSize optional (NFC)Adrian Prantl2019-01-291-4/+2
| | | | | | | | | | | This is a continuation of my quest to make the size 0 a supported value. This reapplies r352394 with additional PDB parser fixes prepared by Pavel Labath! Differential Revision: https://reviews.llvm.org/D57273 llvm-svn: 352521
* Revert "Make Type::GetByteSize optional (NFC)"Adrian Prantl2019-01-281-2/+4
| | | | | | This reverts commit r352394 because it broke three windows-specific tests. llvm-svn: 352434
* Make Type::GetByteSize optional (NFC)Adrian Prantl2019-01-281-4/+2
| | | | | | | | This is a continuation of my quest to make the size 0 a supported value. Differential Revision: https://reviews.llvm.org/D57273 llvm-svn: 352394
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1944-176/+132
| | | | | | | | | | | | | | | | | 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
* Change TypeSystem::GetBitSize() to return an optional result.Adrian Prantl2019-01-161-19/+19
| | | | | | | | | | | | This patch changes the behavior when printing C++ function references: where we previously would get a <could not determine size>, there is now a <no summary available>. It's not clear to me whether this is a bug or an omission, but it's one step further than LLDB previously got. Differential Revision: https://reviews.llvm.org/D56798 llvm-svn: 351376
* Revert "Simplify Value::GetValueByteSize()"Pavel Labath2019-01-161-15/+19
| | | | | | | This reverts commit r351250 because it breaks the SymbolFile/NativePDB/function-types-builtins.cpp. llvm-svn: 351327
* Remove redundant check.Adrian Prantl2019-01-151-5/+3
| | | | llvm-svn: 351274
* Simplify code by using Optional::getValueOr()Adrian Prantl2019-01-151-3/+1
| | | | llvm-svn: 351264
* Simplify Value::GetValueByteSize()Adrian Prantl2019-01-151-19/+15
| | | | llvm-svn: 351250
* Replace auto -> llvm::Optional<uint64_t>Adrian Prantl2019-01-154-8/+12
| | | | | | This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
* Make CompilerType::getBitSize() / getByteSize() return an optional result. NFCAdrian Prantl2019-01-155-28/+38
| | | | | | | | | | | | | | | | | | | | | | | The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-142-32/+31
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.Zachary Turner2019-01-141-2/+3
| | | | | | | | | | | | | This method took a SymbolContext but only actually cared about the case where the m_function member was set. Furthermore, it was intended to be implemented to parse blocks recursively despite not documenting this in its name. So we change the name to indicate that it should be recursive, while also limiting the function parameter to be a Function&. This lets the caller know what is required to use it, as well as letting new implementers know what kind of inputs they need to be prepared to handle. llvm-svn: 351131
* [Core] Use the implementation method GetAddressOf in ValueObjectConstResultChildAleksandr Urakov2019-01-141-0/+5
| | | | | | | | | | | | | | | | | | | | Summary: This patch allows to retrieve an address object for `ValueObject`'s children retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just uses the corresponding method of the implementation object `m_impl` to achieve that. Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille Reviewed By: clayborg Subscribers: leonid.mashinskiy, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56147 llvm-svn: 351065
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-112-17/+15
| | | | | | | | | | | | | | | | Previously all of these functions accepted a SymbolContext&. While a CompileUnit is one member of a SymbolContext, there are also many others, and by passing such a monolithic parameter in this way it makes the requirements and assumptions of the API unclear for both callers as well as implementors. All these methods need is a CompileUnit. By limiting the parameter type in this way, we simplify the code as well as make it self-documenting for both implementers and users. Differential Revision: https://reviews.llvm.org/D56564 llvm-svn: 350943
* Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.Zachary Turner2019-01-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The function SymbolFile::ParseTypes previously accepted a SymbolContext. This makes it extremely difficult to implement faithfully, because you have to account for all possible combinations of members being set in the SymbolContext. On the other hand, no clients of this function actually care about implementing this function to this strict of a standard. AFAICT, there is actually only 1 client in the entire codebase, and it is the function ParseAllDebugSymbols, which is itself only called for testing purposes when dumping information. At this call-site, the only field it sets is the CompileUnit, meaning that an implementer of a SymbolFile need not worry about any examining or handling any other fields which might be set. By restricting this API to accept exactly a CompileUnit& and nothing more, we can simplify the life of new SymbolFile plugin implementers by making it clear exactly what the necessary and sufficient set of functionality they need to implement is, while at the same time removing some dead code that tried to handle other types of SymbolContext fields that were never going to be set anyway. Differential Revision: https://reviews.llvm.org/D56462 llvm-svn: 350889
* Fix symbols.enable-external-lookup description wordingJan Kratochvil2019-01-051-4/+4
| | | | | | | | | D55859 changed "external tools or libraries" to "external sources" according to Pavel Labath. Now it is changed sort of back to "external tools and repositories" according to Adrian Prantl. https://reviews.llvm.org/D55859#1345881 llvm-svn: 350479
* symbols.enable-external-lookup=false on all hosts (not just OSX)Jan Kratochvil2019-01-031-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is already in use: lit/lit-lldb-init: settings set symbols.enable-external-lookup false packages/Python/lldbsuite/test/lldbtest.py: self.runCmd('settings set symbols.enable-external-lookup false') But those are not in effect during MI part of the testsuite. Another problem is that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had no effect on Linux. On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to: AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f (matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21 It is the only testcase with this error. It happens due to: (lldb) target create "/lib64/libstdc++.so.6" Current executable set to '/lib64/libstdc++.so.6' (x86_64). (lldb) b main warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21 Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. which happens only with gcc-base-debuginfo rpm installed (similarly for other packages). It should also speed up the testsuite as it no longer needs to read /usr/lib/debug symbols which have no effect (and should not have any effect) on the testsuite results. Differential Revision: https://reviews.llvm.org/D55859 llvm-svn: 350368
* Simplify ObjectFile::GetArchitecturePavel Labath2019-01-031-4/+2
| | | | | | | | | | | | | | | | Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
* [NFC] Replace `compare` with (in)equality operator where applicable.Jonas Devlieghere2018-12-212-2/+2
| | | | | | | | Using compare is verbose, bug prone and potentially inefficient (because of early termination). Replace relevant call sites with the (in)equality operator. llvm-svn: 349972
* Simplify code for readability. (NFC)Adrian Prantl2018-12-191-6/+3
| | | | llvm-svn: 349700
* Simplify Boolean expressionsJonas Devlieghere2018-12-158-48/+27
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Move Broadcaster+Listener+Event combo from Core into UtilityPavel Labath2018-12-146-1257/+4
| | | | | | | | | | | | | | | | | | Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module. This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board. Reviewers: zturner, jingham, teemperor, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D55361 llvm-svn: 349157
* [Reproducers] Change how reproducers are initialized.Jonas Devlieghere2018-12-031-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov2018-11-301-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file, not only in a symtab. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee. Reviewers: zturner, asmith, labath, clayborg, espindola Reviewed By: clayborg Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 347960
* Remove dead code from IOHandlerAlex Langford2018-11-271-4/+0
| | | | | | This has been dead since 2014 according to the blame llvm-svn: 347721
* [Reproducers] Improve reproducer API and add unit tests.Jonas Devlieghere2018-11-271-8/+13
| | | | | | | | | | | | | | | | | | | When I landed the initial reproducer framework I knew there were some things that needed improvement. Rather than bundling it with a patch that adds more functionality I split it off into this patch. I also think the API is stable enough to add unit testing, which is included in this patch as well. Other improvements include: - Refactor how we initialize the loader and generator. - Improve naming consistency: capture and replay seems the least ambiguous. - Index providers by name and make sure there's only one of each. - Add convenience methods for creating and accessing providers. Differential revision: https://reviews.llvm.org/D54616 llvm-svn: 347716
* Fix copy/paste mistake for r346919.Jonas Devlieghere2018-11-151-1/+1
| | | | llvm-svn: 346921
* [reproducer] Post-commit cleanupJonas Devlieghere2018-11-151-0/+7
| | | | | | | | | After committing the initial reproducer feature I noticed a few small issues which warranted addressing here. It fixes incorrect documentation in the command object and extract some duplicated code into the debugger object. llvm-svn: 346919
* [LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".George Rimar2018-11-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
* Revert r346848 "[LLDB] - Support the single file split DWARF."George Rimar2018-11-141-8/+0
| | | | | | | It broke BB: http://green.lab.llvm.org/green/job/lldb-cmake/12522/testReport/junit/LLDB/Breakpoint/single_file_split_dwarf_test/ llvm-svn: 346853
* [LLDB] - Support the single file split DWARF.George Rimar2018-11-141-0/+8
| | | | | | | | | | | | | | | | | | DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52296 llvm-svn: 346848
OpenPOWER on IntegriCloud