summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwoDwp.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add RTTI support to the SymbolFile class hierarchyAdrian Prantl2019-11-151-0/+2
| | | | Differential Revision: https://reviews.llvm.org/D70322
* DWARF: Don't create lldb CompileUnits for DWARF type unitsPavel Labath2019-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Type units don't represent actual compilations and a lot of the operations that we do with lldb compile units (getting their line tables, variables, etc.) don't make sense for them. There is also a lot more of them (sometimes over 100x), so making them more lightweight pays off. The main change in this patch is that we stop creating lldb CompileUnits for DWARF type units. The trickiest part here is that the SymbolFile interface requires that we assign consecutive sequence IDs to the compile units we create. As DWARF type and compile units can come in any order (in v5), this means we can no longer use 1-1 mapping between DWARF and lldb compile units. Instead I build a translation table between the two indices. To avoid pessimizing the case where there are no type units, I build the translation table only in case we have at least one type unit. Additionaly, I also tried to strenghted type safete by replacing DWARFUnit with DWARFCompileUnit where applicable. Though that was not stricly necessary, I found it a good way to ensure that the transformations I am doing here make sense. In the places where I was changing the function signatures, and where it was obvious that the objects being handled were not null, I also replaced pointers with references. There shouldn't be any major functional change with this patch. The only change I observed is that now the types in the type units will not be parsed when one calls Module::ParseAllDebugSymbols, unless they are referenced from other compile units. This makes sense, given how ParseAllDebugSymbols is implemented (it iterates over all compile units), and it only matters for one hand-writted test where I did not bother to reference the types from the compile units (which I now do). Reviewers: clayborg, JDevlieghere, aprantl Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D63005 llvm-svn: 363250
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Move the codebase to use: DWARFCompileUnit -> DWARFUnitJan Kratochvil2018-03-181-2/+2
| | | | | | | | | | | | Now the codebase can use the DWARFUnit superclass. It will make it later seamlessly work also with DWARFPartialUnit for DWZ. This patch is only a search-and-replace easily undone, nothing interesting in it. Differential revision: https://reviews.llvm.org/D42892 llvm-svn: 327810
* Add support for the DWP debug info formatTamas Berghammer2017-08-251-0/+36
Summary: The DWP (DWARF package) format is used to pack multiple dwo files generated by split-dwarf into a single ELF file to make distributing them easier. It is part of the DWARFv5 spec and can be generated by dwp or llvm-dwp from a set of dwo files. Caviats: * Only the new version of the dwp format is supported (v2 in GNU numbering schema and v5 in the DWARF spec). The old version (v1) is already deprecated but binutils 2.24 still generates that one. * Combining DWP files with module debugging is not yet supported. Subscribers: emaste, mgorny, aprantl Differential Revision: https://reviews.llvm.org/D36062 llvm-svn: 311775
OpenPOWER on IntegriCloud