summaryrefslogtreecommitdiff
path: root/lldb/source/Utility/DataExtractor.cpp
AgeCommit message (Collapse)Author
2023-07-09[lldb] Add missing StringExtras.h includesElliot Goodrich
In preparation for removing the `#include "llvm/ADT/StringExtras.h"` from the header to source file of `llvm/Support/Error.h`, first add in all the missing includes that were previously included transitively through this header. This is fixing all files missed in b0abd4893fa1, 39d8e6e22cd1, and a11efd49266f. Differential Revision: https://reviews.llvm.org/D154775
2023-01-28Use llvm::byteswap instead of ByteSwap_{16,32,64} (NFC)Kazu Hirata
2022-04-05[lldb/source/Utility/DataExtractor.cpp] Update for `llvm::MD5::MD5Result` ↵Argyrios Kyrtzidis
API change
2022-03-14[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDBShafik Yaghmour
Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2021-06-09[lldb] Use C++11 default member initializersJonas Devlieghere
This converts a default constructor's member initializers into C++11 default member initializers. This patch was automatically generated with clang-tidy and the modernize-use-default-member-init check. $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix This is a mass-refactoring patch and this commit will be added to .git-blame-ignore-revs. Differential revision: https://reviews.llvm.org/D103483
2021-05-26[lldb][NFC] Use C++ versions of the deprecated C standard library headersRaphael Isemann
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D103084
2020-07-07[lldb] Fix unaligned load in DataExtractorJonas Devlieghere
Somehow UBSan would only report the unaligned load in TestLinuxCore.py when running the tests with reproducers. This patch fixes the issue by using a memcpy in the GetDouble and the GetFloat method. Differential revision: https://reviews.llvm.org/D83256
2020-06-19[lldb] Replace std::isprint/isspace with llvm's locale-independent versionRaphael Isemann
Summary: LLVM is using its own isPrint/isSpace implementation that doesn't change depending on the current locale. LLDB should do the same to prevent that internal logic changes depending on the set locale. Reviewers: JDevlieghere, labath, mib, totally_not_teemperor Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D82175
2020-06-10[lldb] Replace the LEB128 decoding logic in LLDB's DataExtractor with calls ↵Raphael Isemann
to LLVM's LEB128 implementation Reviewers: labath, JDevlieghere Reviewed By: labath Differential Revision: https://reviews.llvm.org/D81453
2020-06-05[lldb] Fix UBSan regression in GetSLEB128Jan Kratochvil
It regressed recently by my: https://reviews.llvm.org/D81119
2020-06-04[lldb] Fix SLEB128 decodingJan Kratochvil
Bug 46181 shows SLEB128 0xED9A924C00011151 decoded as 0xffffffff80011151. LLDB show a wrong value for function argument https://bugs.llvm.org/show_bug.cgi?id=46181 Differential Revision: https://reviews.llvm.org/D81119
2020-02-25[LLDB] Let DataExtractor deal with two-byte addressesAyke van Laethem
AVR usually uses two byte addresses. By making DataExtractor deal with this, it is possible to load AVR binaries that don't have debug info associated with them. Differential Revision: https://reviews.llvm.org/D73969
2020-02-18[lldb] Remove DataExtractor::GetPointerPavel Labath
This function is equivalent to GetAddress, but getAddress is also present on the llvm version of the data extractor.
2020-02-03[lldb/DataExtractor] Use an early return in GetMaxS64Bitfield, NFCVedant Kumar
Shafik suggested this cleanup in https://reviews.llvm.org/D73913.
2020-02-03[lldb/DataExtractor] Fix UB shift in GetMaxS64BitfieldVedant Kumar
DataExtractor::GetMaxS64Bitfield performs a shift with UB in order to construct a bitmask when bitfield_bit_size is 64. The current implementation actually does “work” in this case, because the assumption that the shift result is 0 holds, and 0 minus 1 gives the all-ones value (the correct mask). However, the more readable/maintainable approach might be to use an off-the-shelf UB-free helper. Fixes a UBSan issue: "col" : 37, "description" : "invalid-shift-exponent", "filename" : "/Users/vsk/src/llvm-project-master/lldb/source/Utility/DataExtractor.cpp", "instrumentation_class" : "UndefinedBehaviorSanitizer", "line" : 615, "memory_address" : 0, "summary" : "Shift exponent 64 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long')", rdar://59117758 Differential Revision: https://reviews.llvm.org/D73913
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-07[lldb][NFC] Use static_cast instead of reinterpret_cast where possibleRaphael Isemann
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2019-12-06[lldb][NFC] Remove ability to pass a custom printf format to ↵Raphael Isemann
DataExtractor::PutToLog This is luckily not used anywhere.
2019-12-05[LLDB] Replacing use of ul suffix in GetMaxU64Bitfield since it not ↵shafik
guarenteed to be 64 bit GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit. So this replacing it with a explicit cast and refactors the code around it to use an early exit. Differential Revision: https://reviews.llvm.org/D70992
2019-10-10[lldb] Fix out of bounds read in DataExtractor::GetCStr and add unit test ↵Raphael Isemann
that function. Summary: The `if (*cstr_end == '\0')` in the previous code checked if the previous loop terminated because it found a null terminator or because it reached the end of the data. However, in the case that we hit the end of the data before finding a null terminator, `cstr_end` points behind the last byte in our data and `*cstr_end` reads the memory behind the array (which may be uninitialised) This patch just rewrites that function use `std::find` and adds the relevant unit tests. Reviewers: labath Reviewed By: labath Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68773 llvm-svn: 374311
2019-05-23[Utility] Modernize C-style catsJonas Devlieghere
Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere
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
2019-03-07Promote more debug-only assertions to regular assertions.Adrian Prantl
llvm-svn: 355569
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-11-11Remove comments after header includes.Jonas Devlieghere
This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
2018-06-26Represent invalid UUIDs as UUIDs with length zeroPavel Labath
Summary: During the previous attempt to generalize the UUID class, it was suggested that we represent invalid UUIDs as length zero (previously, we used an all-zero UUID for that). This meant that some valid build-ids could not be represented (it's possible however unlikely that a checksum of some file would be zero) and complicated adding support for variable length build-ids (should a 16-byte empty UUID compare equal to a 20-byte empty UUID?). This patch resolves these issues by introducing a canonical representation for an invalid UUID. The slight complication here is that some clients (MachO) actually use the all-zero notation to mean "no UUID has been set". To keep this use case working (while making it very explicit about which construction semantices are wanted), replaced the UUID constructors and the SetBytes functions with named factory methods. - "fromData" creates a UUID from the given data, and it treats all bytes equally. - "fromOptionalData" first checks the data contents - if all bytes are zero, it treats this as an invalid/empty UUID. Reviewers: clayborg, sas, lemo, davide, espindola Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D48479 llvm-svn: 335612
2018-04-30Reflow paragraphs in comments.Adrian Prantl
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
2017-10-11Fix dumping of characters with non-standard sizesPetr Pavlu
* Prevent dumping of characters in DumpDataExtractor() with item_byte_size bigger than 8 bytes. This case is not supported by the code and results in a crash because the code calls DataExtractor::GetMaxU64Bitfield() -> GetMaxU64() that asserts for byte size > 8 bytes. * Teach DataExtractor::GetMaxU64(), GetMaxU32(), GetMaxS64() and GetMaxU64_unchecked() how to handle byte sizes that are not a multiple of 2. This allows DumpDataExtractor() to dump characters and booleans with item_byte_size in the interval of [1, 8] bytes. Values that are not a multiple of 2 would previously result in a crash because they were not handled by GetMaxU64(). llvm-svn: 315444
2017-04-06iwyu fixes on lldbUtility.Zachary Turner
This patch makes adjustments to header file includes in lldbUtility based on recommendations by the iwyu tool (include-what-you-use). The goal here is to make sure that all files include the exact set of headers which are needed for that file only, to eliminate cases of dead includes (e.g. someone deleted some code but forgot to delete the header includes that that code necessitated), and to eliminate the case where header includes are picked up transitively. llvm-svn: 299676
2017-03-20Add a function to MD5 a file's contents.Zachary Turner
In doing so, clean up the MD5 interface a little. Most existing users only care about the lower 8 bytes of an MD5, but for some users that care about the upper and lower, there wasn't a good interface. Furthermore, consumers of the MD5 checksum were required to handle endianness details on their own, so it seems reasonable to abstract this into a nicer interface that just gives you the right value. Differential Revision: https://reviews.llvm.org/D31105 llvm-svn: 298322
2017-03-04Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner
llvm-svn: 296943