summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/PDB/PDBLocationToDWARFExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
* DWARFExpression: Simplify class interfacePavel Labath2019-08-271-1/+1
| | | | | | | | | | | | | | | | | Summary: The DWARFExpression methods have a lot of arguments. This removes two of them by removing the ability to slice the expression via two offset+size parameters. This is a functionality that it is not always needed, and when it is, we already have a different handy way of slicing a data extractor which we can use instead. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66745 llvm-svn: 370027
* [DWARFExpression] Remove ctor that takes just a compile unit.Jonas Devlieghere2019-05-281-7/+7
| | | | | | | | | | | | | | | | Like many of our DWARF classes, the DWARFExpression can be initialized in several ways. One such way was through a constructor that takes just the compile unit. This constructor is used to initialize both empty DWARFExpressions, and DWARFExpression that will be populated later. To make the distinction more clear, I changed the constructor to a default constructor and updated its call sites. Where the DWARFExpression was being populated later, I replaced that with a call to the copy assignment constructor. Differential revision: https://reviews.llvm.org/D62425 llvm-svn: 361849
* ObjectFilePECOFF: Create a "container" section spanning the entire module imagePavel Labath2019-02-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-011-466/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Update LLDB for LLVM CodeView API change in r339907Reid Kleckner2018-08-161-329/+329
| | | | llvm-svn: 339910
* Convert a location information from PDB to a DWARF expressionJonas Devlieghere2018-07-131-0/+585
The current version of SymbolFilePDB::ParseVariableForPDBData function always initializes variables with an empty location. This patch adds the converter of a location information from PDB to a DWARF expression, so it becomes possible to watch values of variables of primitive data types. At the moment the converter supports only Static, TLS, RegRel, Enregistered and Constant PDB location types, but it seems that it's enough for most cases. There are still some problems with retrieving values of variables (e.g. we can't watch variables of composite types), but they look not relevant to the conversion to DWARF. Patch by: Aleksandr Urakov Differential revision: https://reviews.llvm.org/D49018 llvm-svn: 336988
OpenPOWER on IntegriCloud