llvm-project.git/lldb/source/Core/DataExtractor.cpp, branch main

Move DataBuffer / DataExtractor and friends from Core -> Utility.

2017-03-04T01:30:05+00:00

llvm-svn: 296943

Move UUID from Core -> Utility.

2017-03-04T01:28:55+00:00

llvm-svn: 296941

Isolate Target-specific functionality of DataExtractor.

2017-03-03T20:57:05+00:00

In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality.  Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area.  Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.

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

llvm-svn: 296910

Move Log from Core -> Utility.

2017-03-03T20:56:28+00:00

All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.

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

llvm-svn: 296909

Remove dependencies from Utility to Core and Target.

2017-02-14T19:06:07+00:00

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

Move classes from Core -> Utility.

2017-02-02T21:39:50+00:00

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

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

2016-11-16T21:15:24+00:00

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

*** This commit represents a complete reformatting of the LLDB source code

2016-09-06T20:57:50+00:00

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

64-bit LEB values are not always correctly decoded due to a casting issue, now they are.

2016-06-28T17:14:18+00:00

 

llvm-svn: 274037

Now that there are no cycles that cause leaks in the disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue.

2016-06-07T23:19:00+00:00



llvm-svn: 272071