This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation. This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.
llvm-svn: 296906
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
this is a resubmission of r280476. The problem with the original commit was that it was printing
out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and
add a unit test covering that case.
llvm-svn: 280480
This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit
breakage, and I did not run the 32-bit test suite before submitting, oops.
llvm-svn: 280478
Summary:
It seems the original intention of the function was printing signed values in decimal format, and
unsigned values in hex (without the leading "0x"). However, signed and unsigned long were
exchanged, which lead to amusing test failures in TestMemoryFind.py.
Instead of just switching the two, I think we should just print everything in decimal here, as
the current behaviour is very confusing (especially when one does not request printing of types).
Nothing seems to depend on this behaviour except and we already have a way for the user to
request the format he wants when printing values for most commands (which presumably does not go
through this function).
I also add a unit tests for the function in question.
Reviewers: clayborg, granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24126
llvm-svn: 280476
Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures.
Reviewers: uweigand, labath
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D20355
llvm-svn: 270062
Recommit modified version of r266311 including build bot regression fix.
This differs from the original r266311 by:
- Fixing Scalar::Promote to correctly zero- or sign-extend value depending
on signedness of the *source* type, not the target type.
- Omitting a few stand-alone fixes that were already committed separately.
llvm-svn: 266422
The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method. Unfortunately, pretty much all of these places
do not handle big-endian systems correctly. While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer. This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.
This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.
This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.
The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed. I've also removed
the Scalar::GetRawBits64 function and its few users.
The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems. GetData now simply calls GetBytes instead of reimplementing
its contents.
Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer. I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.
The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines. Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.
Differential Revision: http://reviews.llvm.org/D18981
llvm-svn: 266311
Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= ().
Reviewers: sagar, tberghammer, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16868
Patch by Marianne Mailhot-Sarrasin
llvm-svn: 260239
Zachary Turner