[lldb] Fix Scalar::GetData for non-multiple-of-8-bits values (#90846)

It was aligning the byte size down. Now it aligns up. This manifested
itself as SBTypeStaticField::GetConstantValue returning a

[lldb] Fix Scalar::GetData for non-multiple-of-8-bits values (#90846)

It was aligning the byte size down. Now it aligns up. This manifested
itself as SBTypeStaticField::GetConstantValue returning a zero-sized
value for `bool` fields (because clang represents bool as a 1-bit
value).

I've changed the code for float Scalars as well, although I'm not aware
of floating point values that are not multiples of 8 bits.

show more ...

[LLDB] Add APFloat helper functions to Scalar class. (#86862)

This adds the ability to create a Scalar from an APFloat, and to create
an APFloat from an APSInt or another APFloat.

[lldb] Scalar::GetValue() should take a Stream by reference (#69231)

This function always expects the pointer to be valid, a reference seems
more appropriate.

Include <cmath> before using std::pow()

Not sure why this is failing for me to build tonight, but either
something in a header somewhere changed or my tools changed, and
it is failing to compile.

[lldb/Utility] Use APSInt in the Scalar class

This enables us to further simplify some code because it no longer needs
to switch on the signedness of the type (APSInt handles that).

[lldb/Utility] Simplify Scalar handling of float types

Similarly to D85836, collapse all Scalar float types to a single enum
value, and use APFloat semantics to differentiate between. This
simplifie

[lldb/Utility] Simplify Scalar handling of float types

Similarly to D85836, collapse all Scalar float types to a single enum
value, and use APFloat semantics to differentiate between. This
simplifies the code, and opens to door to supporting other floating
point semantics (which would be needed for fully supporting
architectures with more interesting float types such as PPC).

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

show more ...

[lldb/Utility] Simplify and generalize Scalar class

The class contains an enum listing all host integer types as well as
some non-host types. This setup is a remnant of a time when this class
was ac

[lldb/Utility] Simplify and generalize Scalar class

The class contains an enum listing all host integer types as well as
some non-host types. This setup is a remnant of a time when this class
was actually implemented in terms of host integer types. Now that we are
using llvm::APInt, they are mostly useless and mean that each function
needs to enumerate all of these cases even though it treats most of them
identically.

I only leave e_sint and e_uint to denote the integer signedness, but I
want to remove that in a follow-up as well.

Removing these cases simplifies most of these functions, with the only
exception being PromoteToMaxType, which can no longer rely on a simple
enum comparison to determine what needs to be promoted.

This also makes the class ready to work with arbitrary integer sizes, so
it does not need to be modified when someone needs to add a larger
integer size.

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

show more ...

[lldb/Utility] Clean up Scalar constructors

- move initialization to initializer lists
- make desctructor non-virtual (nothing else is)
- fix long double constructor so that it actually works

[lldb/Utility] Simplify Scalar::SetValueFromData

The function was fairly complicated and didn't support new bigger
integer sizes. Use llvm function for loading an APInt from memory to
write a unifie

[lldb/Utility] Simplify Scalar::SetValueFromData

The function was fairly complicated and didn't support new bigger
integer sizes. Use llvm function for loading an APInt from memory to
write a unified implementation for all sizes.

show more ...

[lldb/Utility] Rewrite Scalar::SetValueFromCString

The function's reliance on host types meant that it was needlessly
complicated, and did not handle the newer (wider) types. Rewrite it in
terms of

[lldb/Utility] Rewrite Scalar::SetValueFromCString

The function's reliance on host types meant that it was needlessly
complicated, and did not handle the newer (wider) types. Rewrite it in
terms of APInt/APFloat functions to save code and improve functionality.

show more ...

[lldb/Utility] Fix float->integral conversions in Scalar APInt getters

These functions were doing a bitcast on the float value, which is not
consistent with the other getters, which were doing a num

[lldb/Utility] Fix float->integral conversions in Scalar APInt getters

These functions were doing a bitcast on the float value, which is not
consistent with the other getters, which were doing a numeric conversion
(47.0 -> 47). Change these to do numeric conversions too.

show more ...

[lldb/Utility] Merge Scalar::Get(Value)TypeAsCString

[lldb] Fix type conversion in the Scalar getters

Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
co

[lldb] Fix type conversion in the Scalar getters

Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.

These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.

This means that: (unsigned long)(int)-1
is equal to (unsigned long)0xffffffffffffffff
and not (unsigned long)0x00000000ffffffff

Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.

This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

[lldb] Scalar re-fix UB in float->int conversions

The refactor in 48ca15592f1 reintroduced UB when converting out-of-bounds
floating point numbers to integers -- the behavior for ULongLong() was
ori

[lldb] Scalar re-fix UB in float->int conversions

The refactor in 48ca15592f1 reintroduced UB when converting out-of-bounds
floating point numbers to integers -- the behavior for ULongLong() was
originally fixed in r341685, but did not survive my refactor because I
based my template code on one of the methods which did not have this
fix.

This time, I apply the fix to all float->int conversions, instead of
just the "double->unsigned long long" case. I also use a slightly
simpler version of the code, with fewer round-trips
(APFloat->APSInt->native_int vs
APFloat->native_float->APInt->native_int).

I also add some unit tests for the conversions.

show more ...

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

[lldb] Refactor Scalar::TruncOrExtendTo

The "type" argument to the function is mostly useless -- the only
interesting aspect of it is signedness. Pass signedness directly and
compute the value of bi

[lldb] Refactor Scalar::TruncOrExtendTo

The "type" argument to the function is mostly useless -- the only
interesting aspect of it is signedness. Pass signedness directly and
compute the value of bits and signedness fields -- that's exactly
what the single caller of this function does.

show more ...

[Scalar] Fix assignment operator for long long.

Summary:
Assignment operator `operator=(long long)` currently allocates `sizeof(long)`.
On some platforms it works as they have `sizeof(long) == sizeo

[Scalar] Fix assignment operator for long long.

Summary:
Assignment operator `operator=(long long)` currently allocates `sizeof(long)`.
On some platforms it works as they have `sizeof(long) == sizeof(long long)`,
but on others (e.g. Windows) it's not the case.

Reviewed By: labath

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

show more ...

[ADT] Make StringRef's std::string conversion operator explicit

This has the same behavior as converting std::string_view to
std::string. This is an expensive conversion, so explicit conversions
are

[ADT] Make StringRef's std::string conversion operator explicit

This has the same behavior as converting std::string_view to
std::string. This is an expensive conversion, so explicit conversions
are helpful for avoiding unneccessary string copies.

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

Use llvm for dumping DWARF expressions

Summary:
It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo
structs (which is what is needed to turn dwarf register numbers into
strings).

Re

Use llvm for dumping DWARF expressions

Summary:
It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo
structs (which is what is needed to turn dwarf register numbers into
strings).

Reviewers: JDevlieghere, aprantl, jasonmolenda

Subscribers: tatyana-krasnukha, lldb-commits

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

llvm-svn: 373208

show more ...

Implement DW_OP_convert

This patch adds basic support for DW_OP_convert[1] for integer
types. Recent versions of LLVM's optimizer may insert this opcode into
DWARF expressions. DW_OP_convert is effe

Implement DW_OP_convert

This patch adds basic support for DW_OP_convert[1] for integer
types. Recent versions of LLVM's optimizer may insert this opcode into
DWARF expressions. DW_OP_convert is effectively a type cast operation
that takes a reference to a base type DIE (or zero) and then casts the
value at the top of the DWARF stack to that type. Internally this
works by changing the bit size of the APInt that is used as backing
storage for LLDB's DWARF stack.

I managed to write a unit test for this by implementing a mock YAML
object file / module that takes debug info sections in yaml2obj
format.

[1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1

<rdar://problem/48167864>

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

llvm-svn: 371532

show more ...

[unittest] Fix scalar unit test.

The test was using ASSERT_EQ instead of ASSERT_STREQ which meant we were
comparing string addresses instead of the actual string. This caused the
test to fail with w

[unittest] Fix scalar unit test.

The test was using ASSERT_EQ instead of ASSERT_STREQ which meant we were
comparing string addresses instead of the actual string. This caused the
test to fail with with the sanitizers enabled.

llvm-svn: 352780

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

[Scalar] Clarify the constructor from APInt and document through a test.

I want to add 512-bits support but I first want to make sure I'm
not breaking anything obvious. This is the first of a series

[Scalar] Clarify the constructor from APInt and document through a test.

I want to add 512-bits support but I first want to make sure I'm
not breaking anything obvious. This is the first of a series of commit
adding tests. The first oddity found is that Scalar from APInt(s)
always constructed signed. Maybe at some point we want to revisit
this, but at least now we have a test to document how the API behaves.

<rdar://problem/46886288>

llvm-svn: 352103

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