summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/DWARF] Don't automatically search dwo unit attributesPavel Labath2020-01-101-19/+1
| | | | | | | | | | | | This patch removes the code (deep inside DWARFDebugInfoEntry) which automagically returned the attributes of the dwo unit DIE when asking for the attributes of the skeleton unit. This is fairly hacky, and not consistent with how llvm DWARF parser operates. Instead, I change the code the explicitly request (via GetNonSkeletonUnit) the right unit to search (there were just two places that needed this). If it turns out we need this more often, we can create a utility function (external to DWARFUnit) for doing this.
* [lldb/DWARF] Fix mixed v4+v5 location listsPavel Labath2020-01-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Our code was expecting that a single (symbol) file contains only one kind of location lists. This is not correct (on non-apple platforms, at least) as a file can compile units with different dwarf versions. This patch moves the deteremination of location list flavour down to the compile unit level, fixing this problem. I have also tried to rougly align the code with the llvm DWARFUnit. Fully matching the API is not possible because of how lldb's DWARFExpression lives separately from the rest of the DWARF code, but this is at least a step in the right direction. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71751
* [lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistxPavel Labath2019-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for DWARF5 location lists which are specified indirectly, via an index into the debug_loclists offset table. This includes parsing the DW_AT_loclists_base attribute which determines the location of this offset table, and support for new form DW_FORM_loclistx which is used in conjuction with DW_AT_location to refer to the location lists in this way. The code uses the llvm class to parse the offset information, and I've also tried to structure it similarly to how the relevant llvm functionality works. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71268
* [lldb] Improve/fix base address selection in location listsPavel Labath2019-12-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Lldb support base address selection entries in location lists was broken for a long time. This wasn't noticed until llvm started producing these kinds of entries more frequently with r374600. In r374769, I made a quick patch which added sufficient support for them to get the test suite to pass. However, I did not fully understand how this code operates, and so the fix was not complete. Specifically, what was lacking was the ability to handle modules which were not loaded at their preferred load address (for instance, due to ASLR). Now that I better understand how this code works, I've come to the conclusion that the current setup does not provide enough information to correctly process these entries. In the current setup the location lists were parameterized by two addresses: - the distance of the function start from the start of the compile unit. The purpose of this was to make the location ranges relative to the start of the function. - the actual address where the function was loaded at. With this the function-start-relative ranges can be translated to actual memory locations. The reason for the two values, instead of just one (the load bias) is (I think) MachO, where the debug info in the object files will appear to be relative to the address zero, but the actual code it refers to can be moved and reordered by the linker. This means that the location lists need to be "linked" to reflect the locations in the actual linked file. These two bits of information were enough to correctly process location lists which do not contain base address selection entries (and so all entries are relative to the CU base). However, they don't work with them because, in theory two base address can be completely unrelated (as can happen for instace with hot/cold function splitting, where the linker can reorder the two pars arbitrarily). To fix that, I split the first parameter into two: - the compile unit base address - the function start address, as is known in the object file The new algorithm becomes: - the location lists are processed as they were meant to be processed. The CU base address is used as the initial base address value. Base address selection entries can set a new base. - the difference between the "file" and "load" function start addresses is used to compute the load bias. This value is added to the final ranges to get the actual memory location. This algorithm is correct for non-MachO debug info, as there the location lists correctly describe the code in the final executable, and the dynamic linker can just move the entire module, not pieces of it. It will also be correct for MachO if the static linker preserves relative positions of the various parts of the location lists -- I don't know whether it actually does that, but judging by the lack of base address selection support in dsymutil and lldb, this isn't something that has come up in the past. I add a test case which simulates the ASLR scenario and demonstrates that base address selection entries now work correctly here. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70532
* [lldb/DWARF] Switch to llvm debug_rnglists parserPavel Labath2019-12-051-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Our rnglist support was working only for the trivial cases (one CU), because we only ever parsed one contribution out of the debug_rnglists section. This means we were never able to resolve range lists for the second and subsequent units (DW_FORM_sec_offset references came out blang, and DW_FORM_rnglistx references always used the ranges lists from the first unit). Since both llvm and lldb rnglist parsers are sufficiently self-contained, and operate similarly, we can fix this problem by switching to the llvm parser instead. Besides the changes which are due to variations in the interface, the main thing is that now the range list object is a member of the DWARFUnit, instead of the entire symbol file. This ensures that each unit can get it's own private set of range list indices, and is consistent with how llvm's DWARFUnit does it (overall, I've tried to structure the code the same way as the llvm version). I've also added a test case for the two unit scenario. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71021
* [Dwarf] Make dw_tag_t a typedef for llvm::dwarf::Tag instead of uint16_t.Jonas Devlieghere2019-09-251-1/+1
| | | | | | | | | | | | Currently dw_tag_t is a typedef for uint16_t. This patch changes makes dw_tag_t a typedef for llvm::dwarf::Tag. This enables us to use the full power of the DWARF utilities in LLVM without having to do the cast every time. With this approach, we only have to do the cast when reading the ULEB value. Differential revision: https://reviews.llvm.org/D68005 llvm-svn: 372891
* Remove DWARFExpression::LocationListSizePavel Labath2019-08-291-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The only reason for this function's existance is so that we could pass the correct size into the DWARFExpression constructor. However, there is no harm in passing the entire data extractor into the DWARFExpression, since the same code is performing the size determination as well as the subsequent parse. So, if we get malformed input or there's a bug in the parser, we'd compute the wrong size anyway. Additionally, reducing the number of entry points into the location list parsing machinery makes it easier to switch the llvm debug_loc(lists) parsers. While inside, I added a couple of tests for invalid location list handling. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D66789 llvm-svn: 370373
* DWARFExpression: Simplify class interfacePavel Labath2019-08-271-5/+7
| | | | | | | | | | | | | | | | | 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
* Use const auto *Fangrui Song2019-06-291-5/+5
| | | | llvm-svn: 364702
* DWARF: Add support for type units+split dwarf comboPavel Labath2019-06-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With the last round of refactors, supporting type units in dwo files becomes almost trivial. This patch contains a couple of small fixes, which taken as a whole make type units work in the split dwarf scenario (both DWARF4 and DWARF5): - DWARFContext: make sure we actually read the debug_types.dwo section - DWARFUnit: set string offsets base on all units in the dwo file, not just the main CU - ManualDWARFIndex: index all units in the file - SymbolFileDWARFDwo: Search for the single compile unit in the file, as we can no longer assume it will be the first one The last part makes it obvious that there is still some work to be done here, namely that we do not support dwo files with multiple compile units. That is something that should be easier after the DIERef refactors, but it still requires more work. Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as well as a test that checks we behave reasonably in the presence of dwo files with multiple CUs. Reviewers: clayborg, JDevlieghere, aprantl Subscribers: arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63643 llvm-svn: 364274
* DWARF: Add "dwo_num" field to the DIERef classPavel Labath2019-06-211-16/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When dwo support was introduced, it used a trick where debug info entries were referenced by the offset of the compile unit in the main file, but the die offset was relative to the dwo file. Although there was some elegance to it, this representation was starting to reach its breaking point: - the fact that the skeleton compile unit owned the DWO file meant that it was impossible (or at least hard and unintuitive) to support DWO files containing more than one compile unit. These kinds of files are produced by LTO for example. - it made it impossible to reference any DIEs in the skeleton compile unit (although the skeleton units are generally empty, clang still puts some info into them with -fsplit-dwarf-inlining). - (current motivation) it made it very hard to support type units placed in DWO files, as type units don't have any skeleton units which could be referenced in the main file This patch addresses this problem by introducing an new "dwo_num" field to the DIERef class, whose purpose is to identify the dwo file. It's kind of similar to the dwo_id field in DWARF5 unit headers, but while this is a 64bit hash whose main purpose is to catch file mismatches, this is just a smaller integer used to indentify a loaded dwo file. Currently, this is based on the index of the skeleton compile unit which owns the dwo file, but it is intended to be eventually independent of that (to support the LTO use case). Simultaneously the cu_offset is dropped to conserve space, as it is no longer necessary. This means we can remove the "BaseObjectOffset" field from the DWARFUnit class. It also means we can remove some of the workarounds put in place to support the skeleton-unit+dwo-die combo. More work is needed to remove all of them, which is out of scope of this patch. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63428 llvm-svn: 364009
* DWARF: Make DIERefs always validPavel Labath2019-06-191-10/+8
| | | | | | | | | | | | | | | | | | | | | Summary: This patch makes the DIERef class always valid by default constructor and operator bool. This allows one to express the validity of a DIERef in the type system. Places which are working with potentially-invalid DIERefs have been updated to use Optional<DIERef> instead. The constructor taking a DWARFFormValue was not needed, as all places which were constructing a DIERef this way were immediately converting it into a DWARFDIE or a user_id. This can be done without constructing an intermediate DIERef. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63399 llvm-svn: 363767
* Have DWARFUnit store a *reference* to SymbolFileDWARFPavel Labath2019-06-141-12/+9
| | | | | | | | | | | | Previously it was storing a *pointer*, which left open the possibility of this pointer being null. We never made use of that possibility (it does not make sense), and most of the code was already assuming that. However, there were a couple of null-checks scattered around the code. This patch replaces the reference with a pointer, making the non-null-ness explicit, and removes the remaining null-checks. llvm-svn: 363381
* Code and comment cleanups [NFC]Greg Clayton2019-05-301-47/+41
| | | | | | | | | Changes: - update comments to detail the info can come from .debug_info or .debug_types - Rename "debug_info_data" to "data" now that we can get data from .debug_info or .debug_types. - Also call DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) instead of manually grabbing abbreviation. llvm-svn: 362116
* Improve DWARF parsing and accessing by 1% to 2%Greg Clayton2019-05-301-36/+15
| | | | | | | | | | When LLDB first started we didn't have our mmap of the DWARF data done correctly and if the backing file would change we would get live changes as the file changed and it would cause problems. We now mmap correctly and do not run into these issues. There was legacy code in DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) that would always extract the abbrev index each time the function was called to verify that DWARF data hadn't changed and a warning was emitted if it did. We no longer need this and the code was removed. The other thing this function did when it parsed the abbrev index was give us the offset of the first attribute bytes by adding the LEB128 size to the offset. This required an extra parameter to DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) which is now removed. I added "lldb::offset_t DWARFDebugInfoEntry::GetFirstAttributeOffset() const" which calculates this when we need it and modified all sites that need the offset to call it. Now that we aren't decoding and verifying the abbrev index, it speeds up DWARF access by 1% to 2%. Differential Revision: https://reviews.llvm.org/D62634 llvm-svn: 362103
* DWARFDebugInfoEntry: delete unused Extract() and rename FastExtract() to ↵Fangrui Song2019-05-301-165/+6
| | | | | | | | | | | | | Extract() The function Extract() is almost a duplicate of FastExtract() but is not used. Delete it and rename FastExtract() to Extract(). Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D62593 llvm-svn: 362049
* Clean up DWARFDebugInfoEntryFangrui Song2019-05-291-55/+0
| | | | llvm-svn: 361962
* DWARF: Fix address range support in mixed 4+5 scenarioPavel Labath2019-05-291-60/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: debug_ranges got renamed to debug_rnglists in DWARF 5. Prior to this patch lldb was just picking the first section it could find in the file, and using that for all address ranges lookups. This is not correct in case the file contains a mixture of compile units with various standard versions (not a completely unlikely scenario). In this patch I make lldb support reading from both sections simulaneously, and decide the correct section to use based on the version number of the compile unit. SymbolFileDWARF::DebugRanges is split into GetDebugRanges and GetDebugRngLists (the first one is renamed mainly so we can catch all incorrect usages). I tried to structure the code similarly to how llvm handles this logic (hence DWARFUnit::FindRnglistFromOffset/Index), but the implementations are still relatively far from each other. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62302 llvm-svn: 361938
* [DWARFExpression] Remove ctor that takes just a compile unit.Jonas Devlieghere2019-05-281-4/+5
| | | | | | | | | | | | | | | | 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
* Cleanup fixed form sizes.Greg Clayton2019-05-241-13/+8
| | | | | | | | | | | | | The fix form sizes use to have two arrays: one for 4 byte addresses and in for 8 byte addresses. The table had an issue where DW_FORM_flag_present wasn't being represented as a fixed size form because its actual size _is_ zero and zero was used to indicate the form isn't fixed in size. Any code that needed to quickly access the DWARF had to get a FixedFormSizes instance using the address byte size. This fix cleans things up by adding a DWARFFormValue::GetFixedSize() both as a static method and as a member function on DWARFFormValue. It correctly can indicate if a form size is zero. This cleanup is a precursor to a follow up patch where I hope to speed up DWARF parsing. I verified performance doesn't regress by loading hundreds of DWARF files and setting a breakpoint by file and line and by name in files that do not have DWARF indexes. Performance remained consistent between the two approaches. Differential Revision: https://reviews.llvm.org/D62416 llvm-svn: 361675
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Simplify `GetName`+`AppendTypeName` by `DWARFDIE`Jan Kratochvil2019-05-231-162/+2
| | | | | | | | | | | | | | | In D61502#1503247 @clayborg suggested that DWARFUnit *+dw_offset_t can be now replaced by DWARFDIE. It is moved from DWARFDebugInfoEntry to DWARFDIE as noted by @clayborg. I have also removed return type as (1) it was wrong in one case and (2) no existing caller used the return type. I also refactored the deep nesting noted by @JDevlieghere. Differential Revision: https://reviews.llvm.org/D62211 llvm-svn: 361463
* DWARFDebugInfoEntry: remove unused variablePavel Labath2019-05-221-4/+1
| | | | llvm-svn: 361361
* Remove `SymbolFileDWARF *` when there is already `DWARFUnit *`Jan Kratochvil2019-05-211-137/+105
| | | | | | | | | | | | | | In D61502#1503247 @clayborg suggested that SymbolFileDWARF *dwarf2Data is really redundant in all the calls with also having DWARFUnit *cu. So remove it. One `SymbolFileDWARF *` nullptr check (DWARFDebugInfoEntry::GetDIENamesAndRanges) could be removed, other two nullptr checks (DWARFDebugInfoEntry::GetName and DWARFDebugInfoEntry::AppendTypeName) need to stay in place (now for `DWARFUnit *`). Differential Revision: https://reviews.llvm.org/D62011 llvm-svn: 361277
* Permit cross-CU referencesJan Kratochvil2019-05-151-45/+24
| | | | | | | | | | | | | | So far dw_offset_t was global for the whole SymbolFileDWARF but with .debug_types the same dw_offset_t may mean two different things depending on its section (=CU). So references now return whole new referenced DWARFDIE instead of just dw_offset_t. This means that some functions have to now handle 16 bytes instead of 8 bytes but I do not see that anywhere performance critical. Differential Revision: https://reviews.llvm.org/D61502 llvm-svn: 360795
* DWARF: s/CompileUnit/Unit/ in DWARFFormValuePavel Labath2019-05-151-1/+1
| | | | | | | | The class has been converted to use DWARFUnit, but a number of uses of the words compile unit remained. This removes all such references Get/SetCompileUnit becomes Get/SetUnit, and m_cu becomes m_unit. llvm-svn: 360754
* Finish renaming CompileUnit -> UnitJan Kratochvil2019-05-101-1/+1
| | | | | | | | | | | | | D42892 changed a lot of code to use superclass DWARFUnit instead of its subclass DWARFCompileUnit. Finish this change more thoroughly for any *CompileUnit* -> *Unit* names. Later patch will introduce DWARFTypeUnit which needs to be sometimes different from DWARFCompileUnit and it would be confusing without this renaming. Differential Revision: https://reviews.llvm.org/D61501 llvm-svn: 360443
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-38/+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
* Revert "Move the rest of the sections over to DWARFContext."Pavel Labath2019-03-221-40/+24
| | | | | | | | | | This reverts commit r356682 because it breaks the DWO flavours of some tests: lldb-Suite :: lang/c/const_variables/TestConstVariables.py lldb-Suite :: lang/c/local_variables/TestLocalVariables.py lldb-Suite :: lang/c/vla/TestVLA.py llvm-svn: 356773
* Move the rest of the sections over to DWARFContext.Zachary Turner2019-03-211-24/+40
| | | | | | | | | This is mostly mechanical, and just moves the remaining non-DWO related sections over to DWARFContext. Differential Revision: https://reviews.llvm.org/D59611 llvm-svn: 356682
* Delete more dead code.Zachary Turner2019-03-191-39/+3
| | | | | | | | All of this is code that is unreferenced. Removing as much of this as possible makes it more easy to determine what functionality is missing and/or shared between LLVM and LLDB's DWARF interfaces. llvm-svn: 356509
* Delete dead code.Zachary Turner2019-03-191-34/+0
| | | | | | | | | | Most of these are Dump functions that are never called, but there is one instance of entire unused classes (DWARFDebugMacinfo and DWARFDebugMacinfoEntry) which are also unreferenced in the codebase). Differential Revision: https://reviews.llvm.org/D59276 llvm-svn: 356490
* Remove support for DWARF64.Zachary Turner2019-03-121-11/+5
| | | | | | | | | | | 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-121-4/+3
| | | | | | | | | | 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
* [lldb] Fix DW_OP_addrx uses.Ali Tamur2019-03-071-1/+4
| | | | | | | | | | | | | | | | 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
* 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
* [LLDB] - Add support for DW_FORM_rnglistx and relative DW_RLE_* entries.George Rimar2018-11-021-14/+23
| | | | | | | | | This adds support for DW_RLE_base_addressx, DW_RLE_startx_endx, DW_RLE_startx_length, DW_FORM_rnglistx. Differential revision: https://reviews.llvm.org/D53929 llvm-svn: 345958
* [LLDB] - Add support for DW_FORM_addrx[1-4]? forms.George Rimar2018-10-311-0/+6
| | | | | | | | | This adds the support for DW_FORM_addrx, DW_FORM_addrx1, DW_FORM_addrx2, DW_FORM_addrx3, DW_FORM_addrx4 forms. Differential revision: https://reviews.llvm.org/D53813 llvm-svn: 345706
* Recommit r345127 "[LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-251-19/+9
| | | | | | | | | | | | | | | | | | | | | | | | DW_RLE_offset_pair entries (.debug_rnglists)" With the fix: do not forget to hanlde the DW_RLE_start_end, which seems was omited/forgotten/removed by mistake. Original commit message: The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair .debug_rnglists entries Differential revision: https://reviews.llvm.org/D53140 ---- Added : /lldb/trunk/lit/Breakpoint/Inputs/debug_rnglist_offset_pair.yaml Added : /lldb/trunk/lit/Breakpoint/debug_rnglist_offset_pair.test Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h llvm-svn: 345251
* Revert rL345127: [LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-241-9/+19
| | | | | | | | | DW_RLE_offset_pair entries It broke BB: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/11671/consoleFull#434797663d489585b-5106-414a-ac11-3ff90657619c llvm-svn: 345157
* [LLDB] - Add support for DW_RLE_base_address and DW_RLE_offset_pair entries ↵George Rimar2018-10-241-19/+9
| | | | | | | | | | | (.debug_rnglists) The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair .debug_rnglists entries Differential revision: https://reviews.llvm.org/D53140 llvm-svn: 345127
* [LLDB] - Implement the support for the .debug_loclists section.George Rimar2018-10-231-2/+2
| | | | | | | | | | | This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
* Code cleanup: Remove DWARFDebugInfoEntry::m_empty_childrenJan Kratochvil2018-10-161-4/+2
| | | | | | | | | | | | | | | | | | | | | | | It merges DWARFDebugInfoEntry's m_empty_children into m_has_children. m_empty_children was implemented by rL144983. As Greg confirmed m_has_children was used to represent what was in the DWARF in the byte that follows the DW_TAG. m_empty_children was used for DIEs that said they had children but actually only contain a single NULL tag. It is fine to not differentiate between the two. Also changed assert()->lldbassert() for m_abbr_idx 16-bit overflow check as that could be a tough bug to catch if it ever happens. I have checked all calls of HasChildren() that this change should not matter to them. The code even wants to know if there are any children - it does not matter how the children presence is coded in the binary. Patch written based on suggestions by Greg Clayton. Differential Revision: https://reviews.llvm.org/D53321 llvm-svn: 344644
* [LLDB] - Add support for DW_FORM_implicit_const.George Rimar2018-10-121-29/+28
| | | | | | | | | | | | | | | LLDB does not support this DWARF5 form atm. At least gcc emits it in some cases when doing optimization for abbreviations. As far I can tell, clang does not support it yet, though the rest LLVM code already knows about it. The patch adds the support. Differential revision: https://reviews.llvm.org/D52689 llvm-svn: 344328
* [LLDB] - Add basic support for .debug_rnglists section (DWARF5)George Rimar2018-10-101-3/+3
| | | | | | | | | This adds a basic support of the .debug_rnglists section. Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported. Differential revision: https://reviews.llvm.org/D52981 llvm-svn: 344119
* [LLDB] - Improved DWARF5 support.George Rimar2018-09-131-0/+8
| | | | | | | | | This patch improves the support of DWARF5. Particularly the reporting of source code locations. Differential revision: https://reviews.llvm.org/D51935 llvm-svn: 342153
* Fix DWARFUnit::GetUnitDIEPtrOnly stale pointerJan Kratochvil2018-05-291-0/+12
| | | | | | | | | | | | | GetUnitDIEPtrOnly() needs to return pointer to the first DIE. But the first element of m_die_array after ExtractDIEsIfNeeded(true) may move in memory after later ExtractDIEsIfNeeded(false). DWARFDebugInfoEntry::collection m_die_array is std::vector, its data may move during its expansion. Differential revision: https://reviews.llvm.org/D46810 llvm-svn: 333437
* Use DWARFBaseDIE as a compile-time protectionJan Kratochvil2018-05-241-2/+2
| | | | | | | | | As suggested by Pavel Labath in D46810 DWARFUnit::GetUnitDIEOnly() returning a pointer to m_first_die should not permit using methods like GetFirstChild(). Differential revision: https://reviews.llvm.org/D47276 llvm-svn: 333224
* General cleanup to minimize the .debug_types patchGreg Clayton2018-05-091-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | This cleanup is designed to make the https://reviews.llvm.org/D32167 patch smaller and easier to read. Cleanup in this patch: Allow DWARFUnit subclasses to hand out the data that should be used when decoding data for a DIE. The information might be in .debug_info or could be in .debug_types. There is a new virtual function on DWARFUnit that each subclass must override: virtual const lldb_private::DWARFDataExtractor &DWARFUnit::GetData() const; This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different data to be used when decoding the DIE information. Add a new pure virtual function to get the size of the DWARF unit header: virtual uint32_t DWARFUnit::GetHeaderByteSize() const = 0; This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different offsets where the first DIE starts when decoding DIE information from the unit. Added a new function to DWARFDataExtractor to get the size of an offset: size_t DWARFDataExtractor::GetDWARFSizeOfOffset() const; Removed dead dumping and parsing code in the DWARFDebugInfo class. Inlined a bunch of calls in DWARFUnit for accessors that were just returning integer member variables. Renamed DWARFUnit::Size() to DWARFUnit::GetHeaderByteSize() as it clearly states what it is doing and makes more sense. Differential Revision: https://reviews.llvm.org/D46606 llvm-svn: 331892
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-68/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
OpenPOWER on IntegriCloud