[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] 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/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] 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 ...

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

Move DataExtractorTest to unittests/Utility

The DataExtractor class itself was moved to Utility some time ago, but
it seems this was not reflected in the location of the test code. Fix
that.

llvm-s

Move DataExtractorTest to unittests/Utility

The DataExtractor class itself was moved to Utility some time ago, but
it seems this was not reflected in the location of the test code. Fix
that.

llvm-svn: 346867

show more ...