[lldb][ARM] Use portable printf tokens for 64 bit types

Fixes some warnings in the 32 bit build.

[lldb][ARM] Add tests for vpush/vpop D registers

Previously we just checked via S regs and were not checking
memory content after pushes.

The vpush test confirms that the fix in https://reviews.llv

[lldb][ARM] Add tests for vpush/vpop D registers

Previously we just checked via S regs and were not checking
memory content after pushes.

The vpush test confirms that the fix in https://reviews.llvm.org/D130307
is working.

Memory will only be checked if an "after" state is provided.

Reviewed By: clayborg

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

show more ...

[lldb][ARM] Print mismatched registers in emulation tests

Also correct the test failed message. It implies that what
it's done is compare the 'before' and 'ater' states from the
test input.

Except

[lldb][ARM] Print mismatched registers in emulation tests

Also correct the test failed message. It implies that what
it's done is compare the 'before' and 'ater' states from the
test input.

Except that that's the whole point of the test, that the state changes.
It should tell you that it compared the result of the emulation to the
'after'.

Reviewed By: clayborg

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

show more ...

[LLDB][ARM] Generalise adding register state in emulation tests and add D registers

Since some s and d registers overlap we will error if we find both.
This prevents you overwriting one with the oth

[LLDB][ARM] Generalise adding register state in emulation tests and add D registers

Since some s and d registers overlap we will error if we find both.
This prevents you overwriting one with the other in a test case.

Reviewed By: clayborg

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

show more ...

[LLDB][Reliability] Fix register value unpacking

Fix incorrect direction for bit-shifting.

Coverity warning 1355603 (scan.coverity.com)

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

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

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] 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 modernize codebase with modernize-use-nullptr

Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codeba

[lldb] NFC modernize codebase with modernize-use-nullptr

Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.

This is the command I ran and I to fix and format the code base:

```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```

NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.

NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.

Reviewers: martong, espindola, shafik, #lldb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits

Tags: #lldb, #llvm

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

llvm-svn: 361484

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

silence a couple of -Wqual-cast warning from GCC (NFC)

Cast to `const uint8_t *` instead of `uint8_t *` to avoid the warning
from GCC.

EmulationStateARM.cpp:206:34: warning: cast from type 'const

silence a couple of -Wqual-cast warning from GCC (NFC)

Cast to `const uint8_t *` instead of `uint8_t *` to avoid the warning
from GCC.

EmulationStateARM.cpp:206:34: warning: cast from type 'const void*' to type 'uint8_t* {aka unsigned char*}' casts away qualifiers [-Wcast-qual]

Cast to `const uint32_t *` and the explicitly cast away the const-ness
of the value. This seems pretty sketchy as the `DataExtractor` holds a
const reference to the data. However, this is no worse than before.

ObjectFilePECOFF.cpp:540:78: warning: cast from type 'const uint8_t* {aka const unsigned char*}' to type 'uint32_t* {aka unsigned int*}' casts away qualifiers [-Wcast-qual]

llvm-svn: 308489

show more ...

[ARM/Emulation] Remove an unneeded comparison and simplify. NFCI.

reg0 is always zero and comparison to an unsigned always yields
true.

llvm-svn: 300375

Fix two places where an arm instruction emulation method
can dereference misaligned memory.
<rdar://problem/31106315>, <rdar://problem/31106337>

llvm-svn: 298337

Don't allow direct access to StreamString's internal buffer.

This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and inst

Don't allow direct access to StreamString's internal buffer.

This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.

Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.

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

llvm-svn: 287152

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** 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

show more ...

Fix ARM instruction emulation tests on big-endian systems

Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.

In Emulat

Fix ARM instruction emulation tests on big-endian systems

Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.

In EmulateInstructionARM::TestEmulation, code assumes that an
instruction opcode read in from the test file is in target byte
order, but it was in fact read in in host byte order.

More difficult to fix, the EmulationStateARM structure models
the overlapping sregs and dregs by a union in _sd_regs. This
only works correctly if the host is a little-endian system.
I've removed the union in favor of a simple array containing
the 32 sregs, and changed any code accessing dregs to explicitly
use the correct two sregs overlaying that dreg in the proper
target order.

Also, the EmulationStateARM::ReadPseudoMemory and WritePseudoMemory
track memory as a map of uint32_t values in host byte order, and
implement 64-bit memory accessing by splitting them up into two
uint32_t ones. However, callers expect memory contents to be
provided in the form of a byte array (in target byte order).
This means the uint32_t contents need to be byte-swapped on
BE systems, and when splitting up a 64-bit access into two 32-bit
ones, byte order has to be respected.

Differential Revision: http://reviews.llvm.org/D18984

llvm-svn: 266314

show more ...

Fixed a ton of gcc compile warnings

Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.

Differential Revis

Fixed a ton of gcc compile warnings

Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.

Differential Revision: http://reviews.llvm.org/D9674

llvm-svn: 237218

show more ...

Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that

Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.

llvm-svn: 193983

show more ...

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends ar

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.

Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.

This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.

I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.

<rdar://problem/15314068>

llvm-svn: 193907

show more ...

Fix some more mismatched integer types causing compiler warnings.

llvm-svn: 184737

Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting v

Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads

Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".

llvm-svn: 162366

show more ...

While implementing unwind information using UnwindAssemblyInstEmulation I ran
into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses wou

While implementing unwind information using UnwindAssemblyInstEmulation I ran
into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:

virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);

virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);

There is now a new class specifically designed to hold register values:
lldb_private::RegisterValue

The new register context calls that subclasses must implement are:

virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0;

virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0;

The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..).

All RegiterContext and other sources have been switched over to using the new
regiter value class.

llvm-svn: 131096

show more ...

Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added
new OptionGroup subclasses for:
- output file for use with options:
long opts: --outfile <path> --append--output

Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added
new OptionGroup subclasses for:
- output file for use with options:
long opts: --outfile <path> --append--output
short opts: -o <path> -A

- format for use with options:
long opts: --format <format>

- variable object display controls for depth, pointer depth, wether to show
types, show summary, show location, flat output, use objc "po" style summary.

Modified ValueObjectMemory to be able to be created either with a TypeSP or
a ClangASTType.

Switched "memory read" over to use OptionGroup subclasses: one for the outfile
options, one for the command specific options, and one for the format.

llvm-svn: 130334

show more ...

Got the EmulateInstruction CFI code a lot closer to producing CFI data.

Switch the EmulateInstruction to use the standard RegisterInfo structure
that is defined in the lldb private types intead of p

Got the EmulateInstruction CFI code a lot closer to producing CFI data.

Switch the EmulateInstruction to use the standard RegisterInfo structure
that is defined in the lldb private types intead of passing the reg kind and
reg num everywhere. EmulateInstruction subclasses also need to provide
RegisterInfo structs given a reg kind and reg num. This eliminates the need
for the GetRegisterName() virtual function and allows more complete information
to be passed around in the read/write register callbacks. Subclasses should
always provide RegiterInfo structs with the generic register info filled in as
well as at least one kind of register number in the RegisterInfo.kinds[] array.

llvm-svn: 130256

show more ...