[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] Improve RegisterValue::GetScalarValue

Using Scalar::SetValueFromData, we make the code simpler, handle
big-endian systems properly, _and_ avoid type aliasing issues.

[lldb] Rewrite Scalar::GetBytes

This function was modifying and returning pointers to static storage,
which meant that any two accesses to different Scalar objects could
potentially race (depending

[lldb] Rewrite Scalar::GetBytes

This function was modifying and returning pointers to static storage,
which meant that any two accesses to different Scalar objects could
potentially race (depending on which types the objects were storing and
the host endianness).

In the new version the user is responsible for providing a buffer into
which this method will store its binary representation. The main caller
(RegisterValue::GetBytes) already has one such buffer handy, so this did
not require any major rewrites.

To make that work, I've needed to mark the RegisterValue value buffer
mutable -- not an ideal solution, but definitely better than modifying
global storage. This could be further improved by changing
RegisterValue::GetBytes to take a buffer too.

show more ...

Extend max register size to accommodate AArch64 SVE vector regs

Summary: This patch increases maximum register size to 256 bytes to accommodate AArch64 SVE registers maximum possible size of 256 byt

Extend max register size to accommodate AArch64 SVE vector regs

Summary: This patch increases maximum register size to 256 bytes to accommodate AArch64 SVE registers maximum possible size of 256 bytes.

Reviewers: labath, jankratochvil, rengolin

Reviewed By: labath

Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits

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

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

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] Move [SU]Int64ValueIsValidForByteSize to RegisterValue

These functions are an implementation detail of RegisterValue, so
it doesn't make a lot of sense to implement them in a totally
unr

[lldb][NFC] Move [SU]Int64ValueIsValidForByteSize to RegisterValue

These functions are an implementation detail of RegisterValue, so
it doesn't make a lot of sense to implement them in a totally
unrelated class.

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

[Scalar] Implement support for 512-bit values.

(useful, e.g. when reading 512-bits registers, a-la AVX-512).

<rdar://problem/46886288>

llvm-svn: 352639

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

[RegisterValue] Rewrite operator!= in terms of operator==. NFCI.

llvm-svn: 350149

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD

Differential revision: https://reviews.llvm.org/D55584

llvm-svn: 349215

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

Remove outdated TODOs in RegisterValue

These TODOs were for setting m_type in RegisterValue::SetValueFromString
in the case where reg_info's encoding was eEncodingUint or
eEncodingSint. m_type is se

Remove outdated TODOs in RegisterValue

These TODOs were for setting m_type in RegisterValue::SetValueFromString
in the case where reg_info's encoding was eEncodingUint or
eEncodingSint. m_type is set by SetUInt{8,16,32,64.128} during the
SetUInt call.

llvm-svn: 339959

show more ...

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall co

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).

The XCode project will need to be updated after this change.

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

llvm-svn: 339127

show more ...