[lldb/source/Utility/DataExtractor.cpp] Update for `llvm::MD5::MD5Result` API change

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in cl

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

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

show more ...

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy

[lldb] Use C++11 default member initializers

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

show more ...

[lldb][NFC] Use C++ versions of the deprecated C standard library headers

The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivale

[lldb][NFC] Use C++ versions of the deprecated C standard library headers

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

show more ...

[lldb] Fix unaligned load in DataExtractor

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 memcp

[lldb] Fix unaligned load in DataExtractor

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

show more ...

[lldb] Replace std::isprint/isspace with llvm's locale-independent version

Summary:
LLVM is using its own isPrint/isSpace implementation that doesn't change depending on the current locale. LLDB sho

[lldb] Replace std::isprint/isspace with llvm's locale-independent version

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

show more ...

[lldb] Replace the LEB128 decoding logic in LLDB's DataExtractor with calls to LLVM's LEB128 implementation

Reviewers: labath, JDevlieghere

Reviewed By: labath

Differential Revision: https://revie

[lldb] Replace the LEB128 decoding logic in LLDB's DataExtractor with calls to LLVM's LEB128 implementation

Reviewers: labath, JDevlieghere

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D81453

show more ...

[lldb] Fix UBSan regression in GetSLEB128

It regressed recently by my: https://reviews.llvm.org/D81119

[lldb] Fix SLEB128 decoding

Bug 46181 shows SLEB128 0xED9A924C00011151 decoded as 0xffffffff80011151.
LLDB show a wrong value for function argument
https://bugs.llvm.org/show_bug.cgi

[lldb] Fix SLEB128 decoding

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

show more ...

[LLDB] Let DataExtractor deal with two-byte addresses

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
asso

[LLDB] Let DataExtractor deal with two-byte addresses

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

show more ...

[lldb] Remove DataExtractor::GetPointer

This function is equivalent to GetAddress, but getAddress is also
present on the llvm version of the data extractor.

[lldb/DataExtractor] Use an early return in GetMaxS64Bitfield, NFC

Shafik suggested this cleanup in https://reviews.llvm.org/D73913.

[lldb/DataExtractor] Fix UB shift in GetMaxS64Bitfield

DataExtractor::GetMaxS64Bitfield performs a shift with UB in order to
construct a bitmask when bitfield_bit_size is 64. The current
implementat

[lldb/DataExtractor] Fix UB shift in GetMaxS64Bitfield

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

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

show more ...

[lldb][NFC] Use static_cast instead of reinterpret_cast where possible

Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cas

[lldb][NFC] Use static_cast instead of reinterpret_cast where possible

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

show more ...

[lldb][NFC] Remove ability to pass a custom printf format to DataExtractor::PutToLog

This is luckily not used anywhere.

[LLDB] Replacing use of ul suffix in GetMaxU64Bitfield since it not guarenteed to be 64 bit

GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit.

[LLDB] Replacing use of ul suffix in GetMaxU64Bitfield since it not 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

show more ...

[lldb] Fix out of bounds read in DataExtractor::GetCStr and add unit test that function.

Summary:
The `if (*cstr_end == '\0')` in the previous code checked if the previous loop terminated because it

[lldb] Fix out of bounds read in DataExtractor::GetCStr and add unit test 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

show more ...

[Utility] Modernize C-style cats

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-s

[Utility] Modernize C-style cats

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

show more ...

[NFC] Remove ASCII lines from comments

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

[NFC] Remove ASCII lines from comments

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

show more ...

Promote more debug-only assertions to regular assertions.

llvm-svn: 355569

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Remove comments after header includes.

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 of

Remove comments after header includes.

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

show more ...

Represent invalid UUIDs as UUIDs with length zero

Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
u

Represent invalid UUIDs as UUIDs with length zero

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

show more ...

Reflow paragraphs in comments.

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 r

Reflow paragraphs in comments.

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

show more ...