Summary:
When I added the Stream unit test (r338488), the build bots failed due to an out-of-
bound reads when passing an empty string to the PutCStringAsRawHex8 method.
In r338491 I removed the test case to fix the bots.
This patch fixes this in PutCStringAsRawHex8 by always checking for the terminating
null character in the given string (instead of skipping it the first time). It also re-adds the
test case I removed.
Reviewers: vsk
Reviewed By: vsk
Subscribers: vsk, lldb-commits
Differential Revision: https://reviews.llvm.org/D50149
llvm-svn: 338637
The suspicious behavior is obviously because this method reads
OOB memory, so I'll remove it for now and re-add the test alongside
the fix later.
llvm-svn: 338491
Summary:
This adds an initial small unit test for LLDB's Stream class, which should at least cover
most of the functions in the Stream class. StreamString is always in big endian
mode, so that's the only stream byte order path this test covers as of now. Also,
the binary mode still needs to be tested for all print methods.
Also adds some FIXMEs for wrong/strange result values of the Stream class that we hit
while testing those functions.
Reviewers: labath
Reviewed By: labath
Subscribers: probinson, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50027
llvm-svn: 338488
Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:
Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.
Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.
This patch narrows the contract the CompletionRequest has with the different handlers to:
1. A handler can suggest a completion.
2. A handler can ask how many suggestions we already have.
Point 2 obviously means we still have a dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.
Otherwise this patch just completely hides the internal StringList to the different handlers.
The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the `Option` handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.
Reviewers: jingham, davide, labath
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49322
llvm-svn: 338151
Summary:
This patch fixes a few problems with the FormatAnsiTerminalCodes function:
* It does an infinite loop on an unknown color value.
* It crashes when the color value is at the end of the string.
* It deletes the first character behind the color token.
Also added a few tests that reproduce those problems (and test some other corner cases).
Reviewers: davide, labath
Reviewed By: labath
Subscribers: labath, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D49307
llvm-svn: 337189
Summary:
As suggested in D48796, this patch replaces even more internal calls that were using the old
completion API style with a single CompletionRequest. In some cases we also pass an option
vector/index, but as we don't always have this information, it currently is not part of the
CompletionRequest class.
The constructor of the CompletionRequest is now also more sensible. You only pass the
user input, cursor position and your list of matches to the request and the rest will be
inferred (using the same code we used before to calculate this). You also have to pass these
match window parameters to it, even though they are unused right now.
The patch shouldn't change any behavior.
Reviewers: jingham
Reviewed By: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48976
llvm-svn: 337031
Summary:
A subset of the LLDB commands follows this command line interface style:
<command name> [arguments] -- <string suffix>
The parsing code for this interface has been so far been duplicated into the different
command objects which makes it hard to maintain and reuse elsewhere.
This patches improves the situation by adding a OptionsWithRaw class that centralizes
the parsing logic and allows easier testing. The different commands now just call this class to
extract the arguments and the raw suffix from the provided user input.
Reviewers: jingham
Reviewed By: jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49106
llvm-svn: 336723
Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).
This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.
Some Q&A:
Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.
Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.
Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.
Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).
Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).
Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).
Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.
Reviewers: davide, jingham, labath
Reviewed By: jingham
Subscribers: mgorny, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48796
llvm-svn: 336146
Summary:
The data structure is optimized for the case where the UUID size is <=
20 bytes (standard length emitted by the GNU linkers), but larger sizes
are also possible.
I've modified the string conversion function to support the new sizes as
well. For standard UUIDs it maintains the traditional formatting
(4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and
for longer UUIDs it will just repeat the last 6-byte block as long as
necessary.
I've also modified ObjectFileELF to take advantage of the new UUIDs and
avoid manually padding the UUID to 16 bytes. While there, I also made
sure the computed UUID does not depend on host endianness.
Reviewers: clayborg, lemo, sas, davide, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D48633
llvm-svn: 335963
Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
used an all-zero UUID for that). This meant that some valid build-ids
could not be represented (it's possible however unlikely that a checksum of
some file would be zero) and complicated adding support for variable
length build-ids (should a 16-byte empty UUID compare equal to a 20-byte
empty UUID?).
This patch resolves these issues by introducing a canonical
representation for an invalid UUID. The slight complication here is that
some clients (MachO) actually use the all-zero notation to mean "no UUID
has been set". To keep this use case working (while making it very
explicit about which construction semantices are wanted), replaced the
UUID constructors and the SetBytes functions with named factory methods.
- "fromData" creates a UUID from the given data, and it treats all bytes
equally.
- "fromOptionalData" first checks the data contents - if all bytes are
zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
Instead of a separate GetBytes + GetByteSize methods I introduce a
single GetBytes method returning an ArrayRef.
This is NFC cleanup now, but it should make handling arbitrarily-sized
UUIDs cleaner, should we choose to go that way. I also took the
opportunity to add some unit tests for this class.
llvm-svn: 335244
With the recent changes in FileSpec to use LLVM's path style, it is
possible to delegate a bunch of common path operations to LLVM's path
helpers. This means we only have to maintain a single implementation and
at the same time can benefit from the efforts made by the rest of the
LLVM community.
This is part one of a set of patches. There was no obvious way to split
this so I just worked from top to bottom.
Differential revision: https://reviews.llvm.org/D48084
llvm-svn: 334615
When reading DBGSourcePathRemapping from a dSYM, we remove the last two
path components to make the source lookup more general. However, when
dealing with a relative path that has less than 2 components, we ended
up with an invalid (empty) FileSpec.
This patch changes the behavior of removeLastPathComponent to remove the
last path component, if possible. It does this by checking whether a
parent path exists, and if so using that as the new path. We rely
entirely on LLVM's path implementation to do the heavy lifting.
We now also return a boolean which indicates whether the operator was
successful or not.
Differential revision: https://reviews.llvm.org/D47495
rdar://37791687
llvm-svn: 333540
PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those.
Changes include:
Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason.
Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info
Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code.
Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other.
Added tests for absolute, relative and empty paths.
Differential Revision: https://reviews.llvm.org/D47021
llvm-svn: 332842
After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "".
This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename.
Differential Revision: https://reviews.llvm.org/D46783
llvm-svn: 332618
Summary:
1) In logtest.cpp, the name of the file that is reported is not always capitalized, so split the comparison to validate the file (case insensitive) and function (case sensitive) separately
2) Update the gdb remote client tests to work with Python 3. In Python 3, socket sends/receives data as bytes rather than byte strings. This also updates the usage of .hex() - this is no longer available in Python 3, so use hexlify instead
Reviewers: asmith, labath, zturner
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46773
llvm-svn: 332293
Summary:
The llvm version of the enum has the same enumerators, with stlightly
different names, so this is mostly just a search&replace exercise. One
concrete benefit of this is that we can remove the function for
converting between the two enums.
To avoid typing llvm::sys::path::Style::windows everywhere I import the
enum into the FileSpec class, so it can be referenced as
FileSpec::Style::windows.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46753
llvm-svn: 332247
Summary:
now that llvm supports host-agnostic path manipulation functions (and
most of their kinks have been ironed out), we can remove our copies of
the path parsing functions in favour of the llvm ones.
This should be NFC except for the slight difference in handling of the
"//" path, which is now normalized to "/" (this only applies to the
literal "//" path; "//net" and friends still get to keep the two
slashes).
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46687
llvm-svn: 332088
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a process), so it needs to be in a lower layer. Now that the
class has no external dependencies, it can be moved down to the Utility
module.
This removes the last (direct) dependency from the Host module to
Interpreter, so I remove the Interpreter module from Host's dependency
list.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D45480
llvm-svn: 330200
Removing the template arguments and most of the mutating methods from
CleanUp makes it easier to understand and reuse.
In its present state, CleanUp would be too cumbersome to adapt to cases
where multiple objects need to be released. Take for example this change
in swift-lldb:
https://github.com/apple/swift-lldb/pull/334/files#diff-6f474df750f75c8ba675f2a8408a5629R219
This change is simple to express with the new CleanUp, but not so simple
with the old version.
Differential Revision: https://reviews.llvm.org/D43662
llvm-svn: 325964
Summary:
The difference between this and regular LLDB_LOG is that this one clears
the error object unconditionally. This was inspired by the
ObjectFileELF bug (r322664), where the error object was being cleared
only if logging was enabled.
Reviewers: davide, zturner, jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D42182
llvm-svn: 323753
This removes boilerplate for setting up a log channel and capturing the
output from some of the tests. I do this by moving the setup code into a
test fixture and adding a logAndTakeOutput utility function to log some
string and then retrieve it from the log.
I also use some googlemock goodies to simplify a couple of assertions.
llvm-svn: 322653
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Summary:
At present, several gtests in the lldb open source codebase are using
#include statements rooted at $(SOURCE_ROOT)/${LLDB_PROJECT_ROOT}.
This patch cleans up this directory/include structure for both CMake and
Xcode build systems.
rdar://problem/33835795
Reviewers: zturner, jingham, beanz
Reviewed By: beanz
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D36598
llvm-svn: 314849
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
This also moves TaskPool from Utility to Host.
Reviewers: labath, tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37930
llvm-svn: 313637
Summary:
The EncodingError test ensures that trying to encode a multibyte wchar
with a given codepage fails. If setlocale() fails, the encoding is
performed using the current locale, which may or may not fail.
This patch asserts that both setlocale() operations are successful, as
well as falling back to a widely available unibyte encoding for
non-Windows systems.
<rdar://problem/33782806>
Reviewers: zturner, labath, lhames
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D36496
llvm-svn: 310499
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
Summary:
Fetching an input file required about five lines of code, and this was
repeated in multiple unit tests, with slight variations. Add a helper
function for doing that into the lldbUtilityMocks module (which I rename
to lldbUtilityHelpers to commemorate the fact it includes more than
mocks)
Reviewers: zturner, eugene
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34683
llvm-svn: 306668
Summary:
It had a dependency on StringConvert and file reading code, which is not
in Utility. I've replaced that code by equivalent llvm operations.
I've added a unit test to demonstrate that parsing a file still works.
Reviewers: zturner, jingham
Subscribers: kubamracek, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34625
llvm-svn: 306394
Summary:
This adds functions to convert between llvm::Error and Status classes.
Posix errors in Status are represented as llvm::ECError, and the rest as
llvm::StringError.
For the conversion from Error to Status, ECError is again represented as
a posix error in Status, while other errors are stored as generic errors
and only the string value is preserved.
Reviewers: zturner, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33241
llvm-svn: 303348
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
Summary:
Many parallel tasks just want to iterate over all the possible numbers from 0 to N-1. Rather than enqueue N work items, instead just "map" the function across the requested integer space.
Reviewers: clayborg, labath, tberghammer, zturner
Reviewed By: clayborg, zturner
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D32757
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 302223
This was causing a test failure in one of LLDB's tests which
specifically dealt with a limitation in LLVM's implementation
of home_directory() that LLDB's own implementation had worked
around.
This limitation has been addressed in r298513 on the LLVM side,
so the failing test (which is now unnecessary as the limitation
no longer exists) was removed in r298519, allowing this patch to
be re-submitted without modification.
llvm-svn: 298526
Summary:
previously we switched to llvm streams for log output, this completes
the switch for the error streams.
I also clean up the includes and remove the unused argument from
DisableAllLogChannels().
This required adding a bit of boiler plate to convert the output in the
command interpreter, but that should go away when we switch command
results to use llvm streams as well.
Reviewers: zturner, eugene
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D30894
llvm-svn: 297812
Summary:
This fixes two threading issues in the logging code. The access to the
mask and options flags had data races when we were trying to
enable/disable logging while another thread was writing to the log.
Since we can log from almost any context, and we want it to be fast, so
I avoided locking primitives and used atomic variables instead. I have
also removed the (unused) setters for the mask and flags to make sure
that the only way to set them is through the enable/disable channel
functions.
I also add tests, which when run under tsan, verify that the use cases
like "doing an LLDB_LOGV while another thread disables logging" are
data-race-free.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30702
llvm-svn: 297368
it was accessing the details of the Log class directly. Let it go
through the channel class instead.
This also discovered a bug when we were setting but not clearing the log
options when enabling a channel.
llvm-svn: 297053
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
Summary:
I originally set out to move the NameMatches closer to the relevant
function and add some unit tests. However, in the process I've found a
couple of bugs in the implementation:
- the early exits where not always correct:
- (test==pattern) does not mean the match will always suceed because
of regular expressions
- pattern.empty() does not mean the match will fail because the "" is
a valid prefix of any string
So I cleaned up those and added some tests. The only tricky part here
was that regcomp() implementation on darwin did not recognise the empty
string as a regular expression and returned an REG_EMPTY error instead.
The simples fix here seemed to be to replace the empty expression with
an equivalent non-empty one.
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D30094
llvm-svn: 295651
The way of injecting an error into the printf call was not working on
darwin - the C library still happily format the character. It only
returns an error after we use a wide character that does not fit into a
single byte, so switch the test to use that.
llvm-svn: 295443
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
and use it in the appropriate log statements.
Formatting of chrono types in log messages was very clunky. This should
make it much nicer to use and give better output. For details of the
formatting options see the chrono formatter in llvm.
llvm-svn: 294738
Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the first option and standardizes all code to use the second
one.
I've added a LLDB_LOGV macro as a shorthand for if(log &&
log->GetVerbose()) and switched most of the affected log statements to
use that (I've only left a couple of cases that were doing complex
computations in an if(log) block).
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29510
llvm-svn: 294113
This replaces the raw integer timeout parameters in the class with their
chrono-based equivalents. To achieve this, I have moved the Timeout class to a
more generic place and added a quick unit test for it.
llvm-svn: 287920
This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.
Differential Revision: https://reviews.llvm.org/D26481
llvm-svn: 286561
*** 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
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a
little nicer (for example using StringRef member functions instead
of c-style strncmp and related functions) and generally safer
usage.
llvm-svn: 280139
This is a NFC that adds more unit test coverage of the GetHex***
functions as well as the functions to extract numbers with a
specific endianness.
llvm-svn: 280124
MutableArrayRef<T> is essentially a safer version of passing around
(T*, length) pairs and provides some convenient functions for working
with the data without having to manually manipulate indices.
This is a minor NFC.
llvm-svn: 280123
StringExtractor::GetNameColonValue() looks for a substring of the
form "<name>:<value>" and returns <name> and <value> to the caller.
This results in two unnecessary string copies, since the name and
value are not translated in any way and simply returned as-is.
By converting this to return StringRefs we can get rid of hundreds
of string copies.
llvm-svn: 280000
These are helpful on their own, but will be even more useful
once the GetNameColonValue is updated to return StringRefs
instead of std::strings.
llvm-svn: 279919
The purpose of the class is to make it easy to execute tasks in parallel
Basic design goals:
* Have a very lightweight and easy to use interface where a list of
lambdas can be executed in parallel
* Use a global thread pool to limit the number of threads used
(std::async don't do it on Linux) and to eliminate the thread creation
overhead
* Destroy the thread currently not in use to avoid the confusion caused
by them during debugging LLDB
Possible future improvements:
* Possibility to cancel already added, but not yet started tasks
* Parallel for_each implementation
* Optimizations in the thread creation destroyation code
Differential revision: http://reviews.llvm.org/D13727
llvm-svn: 250820
Summary:
Fix StringExtractor.h issues.
* source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
(#include "Utility/StringExtractor.h): Not needed, this is already
included by ProcessKDP.h
* unittests/Utility/StringExtractorTest.cpp
(#include "Utility/StringExtractor.h): Update include path to the
new location.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10995
llvm-svn: 241596
The order of libraries passed to the linker didn't work under linux (you
need the llvm libraries first, then the lldb libraries). I modelled this
after clang's setup here. Seemed simple enough to just be consistent.
llvm-svn: 232461
This makes the directory structure mirror the canonical LLVM
directory structure for a gtest suite.
Additionally, this patch deletes the xcode project. Nobody
is currently depending on this, and it would be better to have
gtest unit tests be hand-maintained in the Xcode workspace
rather than using this python test runner. Patches to that
effect will be submitted as followups.
llvm-svn: 232211
Raphael Isemann