summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile
Commit message (Collapse)AuthorAgeFilesLines
...
* Return Error and Expected from more DWARF interfaces.Zachary Turner2019-03-159-209/+253
| | | | | | | | | | This continues the work of introducing Error and Expected into the DWARF parsing interfaces, this time for the DWARFCompileUnit and DWARFDebugAranges classes. Differential Revision: https://reviews.llvm.org/D59381 llvm-svn: 356278
* Return llvm::Error and llvm::Expected from DWARF parsing code.Zachary Turner2019-03-146-54/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal here is to improve our error handling and error recovery while parsing DWARF, while at the same time getting us closer to being able to merge LLDB's DWARF parser with LLVM's. To this end, I've udpated several of the low-level parsing functions in LLDB to return llvm::Error and llvm::Expected. For now, this only updates LLDB parsing functions and not LLVM. In some ways, this actually gets us *farther* from parity with the two interfaces, because prior to this patch, at least the parsing interfaces were the same (i.e. they all just returned bools, and now with this patch they're diverging). But, I chose to do this for two primary reasons. LLDB has error logging code engrained deep within some of its parsing functions. We don't want to lose this logging information, but obviously LLVM has no logging mechanism at all. So if we're to merge the interfaces, we have to find a way to still allow LLDB to properly report parsing errors while not having the reporting code be inside of LLVM. LLDB (and indeed, LLVM) overload the meaning of the false return value from all of these extraction functions to mean both "We reached the null entry at the end of a list of items, therefore everything was successful" as well as "something bad and unrecoverable happened during parsing". So you would have a lot code that would do something like: while (foo.extract(...)) { ... } But when the loop stops, why did it stop? Did it stop because it finished parsing, or because there was an error? Because of this, in some cases we don't always know whether it is ok to proceed, or how to proceed, but we were doing it anyway. In this patch, I solve the second problem by introducing an enumeration called DWARFEnumState which has two values MoreItems and Complete. Both of these indicate success, but the latter indicates that we reached the null entry. Then, I return this value instead of bool, and convey parsing failure separately. To solve the first problem (and convey parsing failure) these functions now return either llvm::Error or llvm::Expected<DWARFEnumState>. Having this extra bit of information allows us to properly convey all 3 of "error, bail out", "success, call this function again", and "success, don't call this function again". In subsequent patches I plan to extend this pattern to the rest of the parsing interfaces, which will ultimately get all of the log statements and error reporting out of the low level parsing code and into the high level parsing code (e.g. SymbolFileDWARF, DWARFASTParserClang, etc). Eventually, these same changes will have to be backported to LLVM's DWARF parser, but diverging in the short term is the easiest way to converge in the long term. Differential Revision: https://reviews.llvm.org/D59370 llvm-svn: 356190
* Remove support for DWARF64.Zachary Turner2019-03-1210-119/+34
| | | | | | | | | | | LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support for DWARF64 is only partial, and if enabled appears to also not work. Finally, it's untested. Removing this makes merging LLVM and LLDB's DWARF parsing implementations simpler. Differential Revision: https://reviews.llvm.org/D59235 llvm-svn: 355975
* Remove DWARFDIECollection.Zachary Turner2019-03-1214-143/+59
| | | | | | | | | | This is a very thin wrapper over a std::vector<DWARFDIE> and does not seem to provide any real value over just using a container directly. Differential Revision: https://reviews.llvm.org/D59165 llvm-svn: 355974
* Move ElaboratingDIEIterator into implementation file.Zachary Turner2019-03-122-71/+68
| | | | | | | | | | This is not used outside of the private implementation of the class, so hiding in the implementation file is a nice way of simplifying the external interface. Differential Revision: https://reviews.llvm.org/D59164 llvm-svn: 355973
* Correcting some comments in PdbIndex.cpp [NFC]Adrian McCarthy2019-03-121-5/+2
| | | | | | | | | | | | ICF can cause multiple symbols to start at the same virtual address. I plan to handle this shortly, but I wanted to correct the comment for now. Deleted an obsolete comment about adjusting the offset for the magic number at the beginning of the debug info stream. This adjustment is handled at a lower level now. llvm-svn: 355943
* Correctly look up declarations in inline namespacesRaphael Isemann2019-03-122-3/+6
| | | | | | | | | | | | | | | | | | Summary: This patch marks the inline namespaces from DWARF as inline and also ensures that looking up declarations now follows the lookup rules for inline namespaces. Reviewers: aprantl, shafik, serge-sans-paille Reviewed By: aprantl Subscribers: eraman, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D59198 llvm-svn: 355897
* Add a case in SymbolFile{Native,}PDB::TranslateLanguage for SwiftNathan Lanza2019-03-112-0/+4
| | | | | | | | | | Summary: see above Reviewers: compnerd Differential Revision: https://reviews.llvm.org/D59230 llvm-svn: 355883
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-114-18/+18
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* [lldb] Fix DW_OP_addrx uses.Ali Tamur2019-03-073-1/+6
| | | | | | | | | | | | | | | | Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them. Reviewers: aprantl, jingham, davide, clayborg, serge-sans-paille Reviewed By: aprantl Subscribers: jdoerfert, dblaikie, labath, shafik, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59004 llvm-svn: 355629
* Promote more debug-only assertions to regular assertions.Adrian Prantl2019-03-071-1/+1
| | | | llvm-svn: 355569
* Pass ConstString by value (NFC)Adrian Prantl2019-03-0615-59/+57
| | | | | | | | | | | | | | | | | 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
* Resubmit "Don't include UnixSignals.h from Host."Zachary Turner2019-03-061-1/+5
| | | | | | | | This was reverted because it breaks the GreenDragon bot, but the reason for the breakage is lost, so I'm resubmitting this now so we can find out what the problem is. llvm-svn: 355528
* Move RangeMap.h into UtilityPavel Labath2019-03-064-10/+7
| | | | | | | | | | | | | | Summary: This file implements some general purpose data structures, and so it belongs to the Utility module. Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D58970 llvm-svn: 355509
* 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
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-182-2/+2
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* Remove unused extern declaration as removed by D32167Jan Kratochvil2019-02-171-2/+0
| | | | llvm-svn: 354225
* Revert "Don't include UnixSignals.h from Host."Davide Italiano2019-02-151-5/+1
| | | | | | It broke the modules green dragon buildbot. llvm-svn: 354177
* Don't include UnixSignals.h from Host.Zachary Turner2019-02-151-1/+5
| | | | | | | | | | | | | | | | | Host had a function to get the UnixSignals instance corresponding to the current host architecture. This means that Host had to include a file from Target. To break this dependency, just make this a static function directly in UnixSignals. We already have the function UnixSignals::Create(ArchSpec) anyway, so we just need to have UnixSignals::CreateForHost() which determines which value to pass for the ArchSpec. The goal here is to eventually break the Host->Target->Host circular dependency. Differential Revision: https://reviews.llvm.org/D57780 llvm-svn: 354168
* Deserialize Clang module search path from DWARFAdrian Prantl2019-02-1311-43/+58
| | | | | | | | | | | | This patch properly extracts the full submodule path as well as its search paths from DWARF import decls and passes it on to the ClangModulesDeclVendor. rdar://problem/47970144 Differential Revision: https://reviews.llvm.org/D58090 llvm-svn: 353961
* ObjectFilePECOFF: Create a "container" section spanning the entire module imagePavel Labath2019-02-133-15/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is coming from the discussion in D55356 (the most interesting part happened on the mailing list, so it isn't reflected on the review page). In short the issue is that lldb assumes that all bytes of a module image in memory will be backed by a "section". This isn't the case for PECOFF files because the initial bytes of the module image will contain the file header, which does not correspond to any normal section in the file. In particular, this means it is not possible to implement GetBaseAddress function for PECOFF files, because that's supposed point to the first byte of that header. If my (limited) understanding of how PECOFF files work is correct, then the OS is expecded to load the entire module into one continuous chunk of memory. The address of that chunk (+/- ASLR) is given by the "image base" field in the COFF header, and it's size by "image size". All of the COFF sections are then loaded into this range. If that's true, then we can model this behavior in lldb by creating a "container" section to represent the entire module image, and then place other sections inside that. This would make be consistent with how MachO and ELF files are modelled (except that those can have multiple top-level containers as they can be loaded into multiple discontinuous chunks of memory). This change required a small number of fixups in the PDB plugins, which assumed a certain order of sections within the object file (which obivously changes now). I fix this by changing the lookup code to use section IDs (which are unchanged) instead of indexes. This has the nice benefit of removing spurious -1s in the plugins as the section IDs in the pdbs match the 1-based section IDs in the COFF plugin. Besides making the implementation of GetBaseAddress possible, this also improves the lookup of addresses in the gaps between the object file sections, which will now be correctly resolved as belonging to the object file. Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo Reviewed By: clayborg, lemo Subscribers: JDevlieghere, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56537 llvm-svn: 353916
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-139-64/+64
| | | | | | | | | | | | | | | | | 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
* [NativePDB] Process virtual bases in the correct orderAleksandr Urakov2019-02-122-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes virtual bases to be added in the correct order to the bases list. It is important because `VTableContext` (`MicrosoftVTableContext` in our case) uses then the order of virtual bases in the list to restore the virtual table indexes. These indexes are used then to resolve the layout of the virtual bases. We haven't enough information about offsets of virtual bases regarding to the object (moreover, in a common case we can't rely on such information, see the example here: https://reviews.llvm.org/D53506#1272306 ), but there should be enough information to restore the layout of the virtual bases from the indexes in runtime. After D53506 this information is used whenever possible, so there should be no problems with virtual bases' fields reading. Reviewers: zturner, rnk, stella.stamenova Subscribers: abidh, teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56904 llvm-svn: 353806
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-124-15/+15
| | | | | | | | 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
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-115-46/+56
| | | | | | | | | | | 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
* Breakpad: auto-detect path style of file entriesPavel Labath2019-02-112-11/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for auto-detection of path style to SymbolFileBreakpad (similar to how r351328 did the same for DWARF). We guess each file entry separately, as we have no idea which file came from which compile units (and different compile units can have different path styles). The breakpad generates should have already converted the paths to absolute ones, so this guess should be reasonable accurate, but as always with these kinds of things, it is hard to give guarantees about anything. In an attempt to bring some unity to the path guessing logic, I move the guessing logic from inside SymbolFileDWARF into the FileSpec class and have both symbol files use it to implent their desired behavior. Reviewers: clayborg, lemo, JDevlieghere Subscribers: aprantl, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D57895 llvm-svn: 353702
* [NFC] Fix license headers after r352845Aleksandr Urakov2019-02-084-16/+12
| | | | llvm-svn: 353503
* SymbolFileBreakpad: Add line table supportPavel Labath2019-02-072-35/+357
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PDB] Fix build after r352845Aleksandr Urakov2019-02-011-1/+1
| | | | llvm-svn: 352858
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-0115-927/+1306
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | stored relative to VFRAME Summary: This patch makes LLDB able to retrieve proper values for function arguments and local variables stored in PDB relative to VFRAME register. Patch contains retrieval of corresponding FPO table entries from PDB and a generic translator from FPO programs to DWARF expressions to get correct VFRAME value. Patch also improves variables-locations.test and makes this test passable on x86. Patch By: leonid.mashinsky Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov Reviewed By: zturner Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D55122 llvm-svn: 352845
* Fix some warnings in building LLDB.Zachary Turner2019-01-291-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D57413 llvm-svn: 352557
* Make a blind attempt at fixing PDBASTParser nullability issuesAdrian Prantl2019-01-291-2/+6
| | | | llvm-svn: 352548
* Make Type::GetByteSize optional (NFC)Adrian Prantl2019-01-293-31/+36
| | | | | | | | | | | 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
* [NativePDB] Add basic support of methods recostruction in ASTAleksandr Urakov2019-01-294-7/+52
| | | | | | | | | | | | | | | | | | Summary: This patch adds the basic support of methods reconstruction by native PDB plugin. It contains only most obvious changes (it processes LF_ONEMETHOD and LF_METHOD records), some things still remain unsolved: - mangled names retrieving; - support of template methods. Reviewers: zturner, labath, lemo, stella.stamenova Reviewed by: zturner Differential Revision: https://reviews.llvm.org/D56126 llvm-svn: 352464
* Revert "Make Type::GetByteSize optional (NFC)"Adrian Prantl2019-01-282-26/+25
| | | | | | This reverts commit r352394 because it broke three windows-specific tests. llvm-svn: 352434
* Make Type::GetByteSize optional (NFC)Adrian Prantl2019-01-282-25/+26
| | | | | | | | 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
* BreakpadRecords: Address post-commit feedbackPavel Labath2019-01-241-2/+2
| | | | | | | | | | | | | | | Summary: This addresses the issues raised in D56844. It removes the accessors from the breakpad record structures by making the fields public. Also, I refactor the UUID parsing code to remove hard-coded constants. Reviewers: lemo Subscribers: clayborg, lldb-commits Differential Revision: https://reviews.llvm.org/D57037 llvm-svn: 352021
* breakpad: Add FUNC records to the symtabPavel Labath2019-01-221-25/+31
| | | | | | | | | | | | | | | | | | | | This patch extends SymbolFileBreakpad::AddSymbols to include the symbols from the FUNC records too. These symbols come from the debug info and have a size associated with them, so they are given preference in case there is a PUBLIC record for the same address. To achieve this, I first pre-process the symbols into a temporary DenseMap, and then insert the uniqued symbols into the module's symtab. Reviewers: clayborg, lemo, zturner Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56590 llvm-svn: 351781
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1997-388/+291
| | | | | | | | | | | | | | | | | 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
* Breakpad: Extract parsing code into a separate filePavel Labath2019-01-181-20/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This centralizes parsing of breakpad records, which was previously spread out over ObjectFileBreakpad and SymbolFileBreakpad. For each record type X there is a separate breakpad::XRecord class, and an associated parse function. The classes just store the information in the breakpad records in a more accessible form. It is up to the users to determine what to do with that data. This separation also made it possible to write some targeted tests for the parsing code, which was previously unaccessible, so I write a couple of those too. Reviewers: clayborg, lemo, zturner Reviewed By: clayborg Subscribers: mgorny, fedor.sergeev, lldb-commits Differential Revision: https://reviews.llvm.org/D56844 llvm-svn: 351541
* DWARF: Add some support for non-native directory separatorsPavel Labath2019-01-166-77/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we opened a file which was produced on system with different path syntax, we would parse the paths from the debug info incorrectly. The reason for that is that we would parse the paths as they were native. For example this meant that on linux we would treat the entire windows path as a single file name with no directory component, and then we would concatenate that with the single directory component from the DW_AT_comp_dir attribute. When parsing posix paths on windows, we would at least get the directory separators right, but we still would treat the posix paths as relative, and concatenate them where we shouldn't. This patch attempts to remedy this by guessing the path syntax used in each compile unit. (Unfortunately, there is no info in DWARF which would give the definitive path style used by the produces, so guessing is all we can do.) Currently, this guessing is based on the DW_AT_comp_dir attribute of the compile unit, but this can be refined later if needed (for example, the DW_AT_name of the compile unit may also contain some useful info). This style is then used when parsing the line table of that compile unit. This patch is sufficient to make the line tables come out right, and enable breakpoint setting by file name work correctly. Setting a breakpoint by full path still has some kinks (specifically, using a windows-style full path will not work on linux because the path will be parsed as a linux path), but this will require larger changes in how breakpoint setting works. Reviewers: clayborg, zturner, JDevlieghere Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D56543 llvm-svn: 351328
* Replace auto -> llvm::Optional<uint64_t>Adrian Prantl2019-01-151-2/+3
| | | | | | 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-151-7/+11
| | | | | | | | | | | | | | | | | | | | | | | 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
* [LLDB] Remove the unused variable oso_dwarf.David L. Jones2019-01-151-1/+0
| | | | | | Patch by Ali Tamur! (tamur@google.com) llvm-svn: 351158
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-1410-37/+22
| | | | | | | | | | | | | | 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-149-21/+8
| | | | | | | | | | | 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
* [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.Zachary Turner2019-01-1411-50/+49
| | | | | | | | | | | | | 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
* Fix build breaks after the ParseCompileUnit changes.Zachary Turner2019-01-112-12/+9
| | | | | | | The addition of SymbolFileBreakpad crossed paths with my change, so this interface needs to be fixed up as well. llvm-svn: 350950
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-1113-248/+201
| | | | | | | | | | | | | | | | 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
* Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath2019-01-114-0/+386
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud