summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Remove various dead Compare functionsAlex Langford2020-01-081-95/+0
|
* [lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistxPavel Labath2019-12-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | them take raw_ostream Summary: Yet another step on the long road towards getting rid of lldb's Stream class. We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs. I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71052
* Have DWARFUnit store a *reference* to SymbolFileDWARFPavel Labath2019-06-141-26/+13
| | | | | | | | | | | | 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
* Cleanup fixed form sizes.Greg Clayton2019-05-241-86/+53
| | | | | | | | | | | | | 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
* DWARF: Implement DW_AT_signature lookup for type unit supportPavel Labath2019-05-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the main feature of type units. When completing a type, if we encounter a DW_AT_signature attribute, we use it's value to lookup the complete definition of the type in the relevant type unit. To enable this lookup, we build up a map of all type units in a symbol file when parsing the units. Then we consult this map when resolving the DW_AT_signature attribute. I include add a couple of tests which exercise the type lookup feature, including one that ensure we do something reasonable in case we fail to lookup the type. A lot of the ideas in this patch have been taken from D32167 and D61505. Reviewers: clayborg, JDevlieghere, aprantl, alexshap Subscribers: mgrang, lldb-commits Differential Revision: https://reviews.llvm.org/D62246 llvm-svn: 361603
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DWARF: Port debug_addr over to DWARFContextPavel Labath2019-05-211-1/+2
| | | | llvm-svn: 361232
* DWARF: Port most of other sections over to DWARFContextPavel Labath2019-05-201-7/+12
| | | | | | | | This moves the sections from SymbolFileDWARF to DWARFContext, where it was trivial to do so. A couple of sections are still left in SymbolFileDWARF. These will be handled by separate patches. llvm-svn: 361127
* Make DWARFContext dwo-aware and port debug_info sections overPavel Labath2019-05-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The previous attempt and moving section handling over to DWARFContext (D59611) failed because it did not take into account the dwo sections correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the main module for loading the sections, but in the dwo scenario some sections should come from the dwo file. This patch fixes that by making the DWARFContext aware of whether it a dwo context or a regular one. A dwo context gets two sections lists, and it knows where to look for a particular type of a section. This isn't fully consistent with how the llvm DWARFContext behaves, because that one leaves it up to the user to know whether it should ask for a dwo section or not. However, for the time being, it seems useful to have a single entity which knows how to peice together the debug info in dwo and non-dwo scenarios. The rough roadmap for the future is: - port over the rest of the sections to DWARFContext - find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will likely involve adding the ability for the DWARFContext to spawn dwo sub-contexts, similarly to how it's done in llvm. - get rid of the special handling of the "dwo" contexts by making sure everything knows whether it should ask for the .dwo version of the section or not (similarly to how llvm's DWARFUnits do that) To demonstrate how the DWARFContext should behave in this new world, I port the debug_info section (which is debug_info.dwo in the dwo file) handling to DWARFContext. The rest of the sections will come in subsequent patches. Reviewers: aprantl, clayborg, JDevlieghere Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D62012 llvm-svn: 361000
* DWARF: Add ability to reference debug info coming from multiple sectionsPavel Labath2019-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one debug-info-bearing sections (as is the case with type units in DWARF v4). The changes here can be classified into roughly three categories: - the code which addresses a debug info by offset gets an additional argument, which specifies the section one should look into. - the DIERef class also gets an additional member variable specifying the section. This way, code dealing with DIERefs can know which section is the object referring to. - the user_id_t encoding steals one bit from the dwarf_id field to store the section. This means the total number of separate object files (apple .o, or normal .dwo) is limited to 2 billion, but that is fine as it's not possible to hit that number without switching to DWARF64 anyway. This patch is functionally equivalent to (and inspired by) the two patches (D61503 and D61504) by Jan Kratochvil, but there are differences in the implementation: - it uses an enum instead of a bool flag to differentiate the sections - it increases the size of DIERef struct instead of reducing the amount of addressable debug info - it sets up DWARFDebugInfo to store the units in a single vector instead of two. This sets us up for the future in which type units can also live in the debug_info section, and I believe it's cleaner because there's no need for unit index remapping There are no tests with this patch as this is essentially NFC until we start parsing type units from the debug_types section. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61908 llvm-svn: 360872
* Permit cross-CU referencesJan Kratochvil2019-05-151-10/+26
| | | | | | | | | | | | | | 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-44/+36
| | | | | | | | 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
* Fix a "memset clearing an object of non-trivial type" warning in DWARFFormValuePavel Labath2019-03-271-1/+1
| | | | | | | | This is diagnosed by gcc-8. The ValueType struct already has a default constructor which performs zero-initialization, so we can just call that instead of using memset. llvm-svn: 357056
* Revert "Move the rest of the sections over to DWARFContext."Pavel Labath2019-03-221-14/+9
| | | | | | | | | | 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-9/+14
| | | | | | | | | 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
* Remove support for DWARF64.Zachary Turner2019-03-121-62/+12
| | | | | | | | | | | 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
* [lldb] Fix DW_OP_addrx uses.Ali Tamur2019-03-071-0/+1
| | | | | | | | | | | | | | | | 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
* DWARF: Fix a bug in array size computationPavel Labath2018-12-271-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r346165 introduced a bug, where we would fail to parse the size of an array if that size happened to match an existing die offset. The logic was: if (DWARFDIE count = die.GetReferencedDie(DW_AT_count)) num_elements = compute_vla_size(count); else num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array The problem with this logic was that GetReferencedDie did not take the form class of the attribute into account, and would happily return a die reference for any form, if its value happened to match some die. As this behavior is inconsistent with how llvm's DWARFFormValue class operates, I chose to fix the problem by making our version of this class match the llvm behavior. For this to work, I had to add an explicit form class check to the .apple_XXX tables parsing code, because they do (incorrectly?) use data forms as die references. Reviewers: aprantl, clayborg Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D55991 llvm-svn: 350086
* [LLDB] - Improve the support of .debug_str_offsets/.debug_str_offsets.dwoGeorge Rimar2018-11-291-15/+2
| | | | | | | | | | | | | | | | | A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute that points to the first string offset of the CU contribution to the .debug_str_offsets. At the same time, when we use split dwarf, the corresponding split debug unit also may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo. In that case, DWO does not contain DW_AT_str_offsets_base, but LLDB still need to know and skip the .debug_str_offsets.dwo section header to access the offsets. The patch implements the support of DW_AT_str_offsets_base. Differential revision: https://reviews.llvm.org/D54844 llvm-svn: 347859
* [LLDB] - Add support for DW_FORM_rnglistx and relative DW_RLE_* entries.George Rimar2018-11-021-0/+3
| | | | | | | | | 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] - Regroup the switch entries in DWARFFormValue::ExtractValue. NFC.George Rimar2018-10-311-60/+26
| | | | | | | | This is NFC to clean up the `DWARFFormValue::ExtractValue`. It groups similar `DW_FORM_*` and removes an excessive assignment of `ref_addr_size` (it was assigned right after in any case). llvm-svn: 345733
* [LLDB] - Add support for DW_FORM_addrx[1-4]? forms.George Rimar2018-10-311-1/+14
| | | | | | | | | 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
* [LLDB] - Add support for DW_FORM_implicit_const.George Rimar2018-10-121-0/+8
| | | | | | | | | | | | | | | 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] - Improved DWARF5 support.George Rimar2018-09-131-36/+103
| | | | | | | | | This patch improves the support of DWARF5. Particularly the reporting of source code locations. Differential revision: https://reviews.llvm.org/D51935 llvm-svn: 342153
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move the codebase to use: DWARFCompileUnit -> DWARFUnitJan Kratochvil2018-03-181-8/+8
| | | | | | | | | | | | 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
* Fix LLDB crash accessing unknown DW_FORM_* attributesJan Kratochvil2017-07-311-0/+36
| | | | | | | | | | | | | | | | Current LLDB (that is without DWZ support) crashes accessing Fedora debug info: READ of size 8 at 0x60200000ffc8 thread T0 #0 in DWARFDebugInfoEntry::BuildAddressRangeTable(SymbolFileDWARF*, DWARFCompileUnit const*, DWARFDebugAranges*) const tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1336 Greg Clayton: We will need a warning to be emitted in SymbolFileDWARF::CalculateAbilities() stating we won't parse the DWARF due to "unsupported DW_FORM value of 0x1f20". Patch has been mostly written by Greg Clayton. Differential revision: https://reviews.llvm.org/D35622 llvm-svn: 309581
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Remove a couple of Stream flagsPavel Labath2017-01-131-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I came across this while trying to understand what Log::Debug does. It turns out it does not do anything, as there is no instance of someone setting a debug flag on a stream. The same is true for the Verbose and AddPrefix flags. Removing these will enable some cleanups in the Logging class, and it brings us closer towards the long term goal of standardizing on llvm stream classes. I have removed these flags and all code the code which tested for their presence -- there wasn't much of it, mostly in SymbolFileDWARF, which is probably going away at some point anyway. The eBinary flag still has some users, so I am letting it life for the time being. Reviewers: clayborg, zturner Subscribers: aprantl, beanz, lldb-commits Differential Revision: https://reviews.llvm.org/D28616 llvm-svn: 291895
* Make lldb -Werror clean for -Wstring-conversionDavid Blaikie2017-01-061-4/+3
| | | | | | | | | Also found/fixed one bug identified by this warning in RenderScriptx86ABIFixups.cpp where a string literal was being used in an effort to provide a name for an instruction/register, but was instead being passed as the bool 'isVolatile' parameter. llvm-svn: 291198
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-506/+562
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fix incorrect form test in SymbolFileDWARFPavel Labath2016-07-261-0/+1
| | | | | | | | | | | | | | | | | | Summary: We were checking whether an attribute is in block form by getting the block data pointer, which was not correct as the pointer be null even if the attribute is in block form. Other places in the file already use the correct test. To make this work, I've needed to add DW_FORM_exprlock to the list of "block" forms, which seems correct as that is how we are parsing it. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D22756 llvm-svn: 276735
* When support for DWO files was added, there were two ways to pass ↵Greg Clayton2016-03-301-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb::user_id_t out to the rest of LLDB: 1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset 2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset There was a mixing and matching of this and it wasn't done consistently. Major changes include: The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF: DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf) It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF. The function: lldb::user_id_t DIERef::GetUID() const; Now becomes lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const; Again, we need the DWARF file to encode it correctly. This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like: 1 - encode a dw_offset_t into a lldb::user_id_t 2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t 3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type. There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext. If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map. <rdar://problem/25200976> llvm-svn: 264909
* Major DWARF cleanup.Greg Clayton2015-08-261-17/+20
| | | | | | | | | | Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together. There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually. This paves to the way for some modifications that are coming for DWO. llvm-svn: 246100
* Add support for DW_FORM_GNU_[addr,str]_indexTamas Berghammer2015-08-251-25/+62
| | | | | | | | | These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
* Fix buffer overflow for fixed_form_sizesTamas Berghammer2015-08-251-5/+5
| | | | | | | | | | The array is indexed by the value in the DW_FORM filed what can be bigger then the size of the array. This CL add bound checking to avoid buffer overflows Differential revision: http://reviews.llvm.org/D12239 llvm-svn: 245930
* Fixed a ton of gcc compile warningsVince Harron2015-05-131-1/+1
| | | | | | | | | | Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
* Fixed an issue where a DW_FORM_ref{2,4,8} might be extracted incorrectly ↵Greg Clayton2014-11-221-54/+41
| | | | | | | | | | because the wrong compile unit was being used to calculate the compile unit relative offset. This was fixed by making the DWARFFormValue contain the compile unit that it needs so it can decode its form value correctly. Any form value that requires a compile unit will now assert. If any of the assertions that were added are triggered, then code that led to the extraction of the form value without properly setting the compile unit must be fixed immediately. <rdar://problem/19035440> llvm-svn: 222602
* DWARF64 FixesTodd Fiala2014-09-111-19/+73
| | | | | | | | | | | | | | | | 1. DW_FORM_strp and DW_FORM_sec_offset are 64bits for DWARF64 / 32bits for DWARF32 They are different from DW_FORM_addr, whose size is specified in .debug_info 2. Bump DWARF version support form [2,3] to [2,4] in DWARFDebugLine.cpp 3. Fix DWARFDebugLine to support DWARF64 See http://reviews.llvm.org/D5307 for more details. Reviewed by Greg Clayton and Jason Molenda. Change by Tong Shen. llvm-svn: 217607
* Fix typos.Bruce Mitchener2014-07-081-1/+1
| | | | llvm-svn: 212553
* Introduce DWARFDataExtractor for 64-Bit DWARF parsingEd Maste2013-10-241-6/+6
| | | | | Review: http://llvm-reviews.chandlerc.com/D2007 llvm-svn: 193368
* <rdar://problem/13561911>Greg Clayton2013-04-031-5/+19
| | | | | | Modify LLDB to handle DW_FORM_ref_addr attributes for DWARF3 and DWARF4. llvm-svn: 178696
* <rdar://problem/13069948>Greg Clayton2013-01-251-3/+3
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-4/+4
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-69/+69
| | | | llvm-svn: 160338
* Added support for the DWARF 4 DW_FORM values.Greg Clayton2012-02-221-140/+66
| | | | llvm-svn: 151202
* Added a new class called lldb_private::SymbolFileType which is designed toGreg Clayton2011-12-081-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | take a SymbolFile reference and a lldb::user_id_t and be used in objects which represent things in debug symbols that have types where we don't need to know the true type yet, such as in lldb_private::Variable objects. This allows us to defer resolving the type until something is used. More specifically this allows us to get 1000 local variables from the current function, and if the user types "frame variable argc", we end up _only_ resolving the type for "argc" and not for the 999 other local variables. We can expand the use of this as needed in the future. Modified the DWARFMappedHash class to be able to read the HashData that has more than just the DIE offset. It currently will read the atoms in the header definition and read the data correctly. Currently only the DIE offset and type flags are supported. This is needed for adding type flags to the .apple_types hash accelerator tables. Fixed a assertion crash that would happen if we have a variable that had a DW_AT_const_value instead of a location where "location.LocationContains_DW_OP_addr()" would end up asserting when it tried to parse the variable location as a DWARF opcode list. Decreased the amount of memory that LLDB would use when evaluating an expression by 3x - 4x for clang. There was a place in the namespace lookup code that was parsing all namespaces with a certain name in a DWARF file instead of stopping when it found the first match. This was causing all of the compile units with a matching namespace to get parsed into memory and causing unnecessary memory bloat. Improved "Target::EvaluateExpression(...)" to not try and find a variable when the expression contains characters that would certainly cause an expression to need to be evaluated by the debugger. llvm-svn: 146130
* Update declarations for all functions/methods that accept printf-styleJason Molenda2011-09-201-1/+1
| | | | | | | | stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
OpenPOWER on IntegriCloud