Loading a shared library can require a large amount of work; rather than do that serially for each library,
this patch will allow parallelization of the symbols and debug info name indexes.
From scott.smith@purestorage.comhttps://reviews.llvm.org/D32598
llvm-svn: 301609
ValueObject methods.
Using ArrayRef allows us to remove some overloads, work with more array-like
types, and avoid some std::vector temporaries.
https://reviews.llvm.org/D32518
llvm-svn: 301441
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
llvm-svn: 300836
This adjusts header file includes for headers and source files
in Core. In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway. In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need. Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.
llvm-svn: 299714
Summary:
Calling ValueObject::SetName from a sythetic child provider would change
the underying value object used for the non-synthetic child as well what
is clearly unintentional.
Reviewers: jingham, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31371
llvm-svn: 299259
Summary:
After this change a sythetic child provider can generate a special child
named "$$dereference$$" what if present is used when "operator*" or
"operator->" used on a ValueObject. The goal of the change is to make
expressions like "up->foo" work inside the "frame variable" command.
Reviewers: labath, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31368
llvm-svn: 299251
Summary:
NetBSD native threads are printed as 64-bit unsigned integers.
The underlying system type of a thread identity is lwpid_t of type int32_t. For consistency with Linux and FreeBSD share the 64-bit unsigned integer type.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, kettenis, joerg, emaste
Reviewed By: labath, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31132
llvm-svn: 298405
This fixes a bug introduced by r291559. The Module's FindType was
passing the original name not the basename in the case where it didn't
find any separators. I also added a testcase for this.
<rdar://problem/31159173>
llvm-svn: 298331
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
This is necessary to get debug builds of unit tests working on linux.
I think we are at a point where removing dependencies does not prevent
us from depending on the whole world yet. What it does do though, is
make the dependency chains longer as the dependency graph gets sparser,
which means we need to repeat the libraries more times to get the thing
to link.
llvm-svn: 297369
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
this reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat
functionality is not a drop-in replacement for lldb's. The former is
based on stat(2) (which does symlink resolution), while the latter is
based on lstat(2) (which does not).
This also reverts subsequent build fixes (r297128, r297120, 297117) and
r297119 (Remove FileSpec dependency on FileSystem) which builds on top
of this.
llvm-svn: 297139
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.
Differential Revision: https://reviews.llvm.org/D30624
llvm-svn: 297116
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.
Differential Revision: https://reviews.llvm.org/D30622
llvm-svn: 297095
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
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:
It does not change members or call non-const members.
HostInfo::GetArchitecture() returns a const object ref (maybe others?),
which can't access the non-const function.
Reviewers: labath, eugene
Reviewed By: labath, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30515
Author: Jason Majors <jmajors@google.com>
llvm-svn: 296868
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.
llvm-svn: 296855
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the channel. Fix that and add a
test.
llvm-svn: 296329
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which means LLDB's custom mmapping code is redundant.
So this patch deletes it all and uses LLVM's code instead.
In the future, we could take this one step further and delete
even the lldb DataBuffer base class and rely entirely on
LLVM's facilities, but this is a job for another day.
Differential Revision: https://reviews.llvm.org/D30054
llvm-svn: 296159
Summary:
The code was attempting to copy the shared pointer member in order to
guarantee atomicity, but this is not enough. Instead, protect the
pointer with a proper read-write mutex.
This bug was present here for a long time, but my recent refactors must
have altered the timings slightly, such that now this fails fairly often
when running the tests: the test runner runs the "log disable" command
just as the thread monitoring the lldb-server child is about to report
that the server has exited.
I add a test case for this. It's not possible to reproduce the race
deterministically in normal circumstances, but I have verified that
before the fix, the test failed when run under tsan, and was running
fine afterwards.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30168
llvm-svn: 295712
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
Changes wrt. previous version:
- add #include <atomic>: fix build on windows
- add extra {} around the string literals used to initialize
llvm::StringLiteral: fix gcc build
llvm-svn: 295442
Summary:
We currently have two log channel registration mechanisms. One uses a
set of function pointers and the other one is based on the
PluginManager.
The PluginManager dependency is unfortunate, as logging
is also used in lldb-server, and the PluginManager pulls in a lot of
classes which are not used in lldb-server.
Both approach have the problem that they leave too much to do for the
user, and so the individual log channels end up reimplementing command
line argument parsing, category listing, etc.
Here, I replace the PluginManager-based approach with a one. The new API
is more declarative, so the user only needs to specify the list of list
of channels, their descriptions, etc., and all the common tasks like
enabling/disabling categories are hadled by common code. I migrate the
LogChannelDWARF (only user of the PluginManager method) to the new API.
In the follow-up commits I'll replace the other channels with something
similar.
Reviewers: clayborg, zturner, beanz
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D29895
llvm-svn: 295190
Summary:
It turns out listing each library twice is not enough to resolve all
references in a debug build on linux - a number of executables fails to
link with random symbols missing. Increasing the number to three seems
to be enough. The choice of lldbCore to set the multiplicity on is
somewhat arbitrary, but it seems fitting, as it is the biggest layering
transgressor.
Reviewers: beanz
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D29888
llvm-svn: 295189
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
Summary:
We've had two ways to print a "debug" log message.
- Log::GetDebug() was testing a Stream flag which was never set.
- Log::Debug() was checking for the presence of "log enable --debug"
flag.
Given that these two were used very rarely and we already have a
different way to specify "I want a more verbose log", I propose to remove
these two functions and migrate the callers to LLDB_LOGV. This commit
does that.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29823
llvm-svn: 294939
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:
This converts LLDB's logging to use llvm streams instead of
lldb_private::Stream and friends. The changes are mostly
straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream.
The part worth calling out is the rewrite of the StreamCallback class.
Previously this class contained a per-thread buffer of data written. I
assume this had something to do with it trying to make sure each log
line is delivered as a single event, instead of multiple (possibly
interleaved) events. However, this is no longer relevant as the Log
class already writes things to a temporary buffer and then delivers the
message as a single "write", so I have just removed the code in
question.
Reviewers: zturner, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29615
llvm-svn: 294736
Instead just rely on LLDB_LOG().
This is part of an effort to sort out dependency hell in LLDB.
Error is in Utility, but Log is in Core. Core can depend on
Utility, but not vice versa. So this patch moves the knowledge
about how to log Errors from the Error class to the Log file.
Differential Revision: https://reviews.llvm.org/D29514
llvm-svn: 294210
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
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 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
Summary:
This patch adds accurate dependency specifications to the mail LLDB libraries and tools.
In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way.
For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up.
Reviewers: labath, zturner
Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell
Differential Revision: https://reviews.llvm.org/D29333
llvm-svn: 293686
header line, backtrace output) was to remove the current pc value
from frames where we have source level information. We've been
discussing this for the past week and based on input from a group
of low level users, I believe this is the wrong default behavior
for the command line lldb tool.
lldb's backtrace will include the pc value for all stack frames
regardless of whether they have source level debug information or
not.
A related part of r286288 removes the byte offset printing for
functions with source level information (e.g. "main + 22 sourcefile.c:10"
is printed as "main sourcefile.c:10"). I don't see a compelling
case for changing this part of 286288 so I'm leaving that as-is
(in addition to the rest of 286288 which is clearly better than
the previous output style).
<rdar://problem/30083904>
llvm-svn: 293366
Summary: This commit adds an option to set PC to the entry point of the file loaded using "target module load" command. In D28804, Greg asked me to separate this part under a different option.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D28944
llvm-svn: 292989
For bare-metal targets, lldb was missing a command like 'load' in gdb
which can be used to create executable image on the target. This was
discussed in
http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html
This commits adds an option to "target module load" command to provide
that functionality. It does not set the PC to entry address which will
be done separately.
Reviewed in https://reviews.llvm.org/D28804
llvm-svn: 292499
This adds the LLDB_LOG macro, which enables one to write more succinct log
statements.
if (log)
log->Printf("log something: %d", var);
becomes
LLDB_LOG(log, "log something: {0}, var);
The macro still internally does the "if(log)" dance, so the arguments are only
evaluated if logging is enabled, meaning it has the same overhead as the
previous syntax.
Additionally, the log statements will be automatically prefixed with the file
and function generating the log (if the corresponding new argument to the "log
enable" command is enabled), so one does not need to manually specify this in
the log statement.
It also uses the new llvm formatv syntax, which means we don't have to worry
about PRIx64 macros and similar, and we can log complex object (llvm::StringRef,
lldb_private::Error, ...) more easily.
Differential Revision: https://reviews.llvm.org/D27459
llvm-svn: 292360
Summary:
I came across this while trying to understand what Log::Debug does. It turns out
it does not do anything, as there is no instance of someone setting a debug flag
on a stream. The same is true for the Verbose and AddPrefix flags. Removing
these will enable some cleanups in the Logging class, and it brings us closer
towards the long term goal of standardizing on llvm stream classes.
I have removed these flags and all code the code which tested for their
presence -- there wasn't much of it, mostly in SymbolFileDWARF, which is
probably going away at some point anyway.
The eBinary flag still has some users, so I am letting it life for the time
being.
Reviewers: clayborg, zturner
Subscribers: aprantl, beanz, lldb-commits
Differential Revision: https://reviews.llvm.org/D28616
llvm-svn: 291895
Previously it failed to handle nested types inside templated classes
making it impossible to look up these types using the fully qualified
name.
Differential revision: https://reviews.llvm.org/D28466
llvm-svn: 291559
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was being used in an
effort to provide a name for an instruction/register, but was instead
being passed as the bool 'isVolatile' parameter.
llvm-svn: 291198
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored
to properly substitute primitive types using a hook in the itanium demangler,
and updated after the previous patch went stale
The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement
primitive type parameter as before but parses it using the FastDemangler, which
has been modified to be able to notify clients of parse events (primitive types
at this point).
Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so
that we don't try and resolve the same invalid candidate multiple times.
Differential Revision: https://reviews.llvm.org/D27223
Subscribers: lldb-commits
llvm-svn: 290117
This adds formatv-backed formatting functions in various
places in LLDB such as StreamString, logging, constructing
error messages, etc. A couple of callsites are changed
from Printf style syntax to formatv style syntax to
illustrate its usage. Additionally, a FileSpec formatter
is introduced so that FileSpecs can be formatted natively.
Differential Revision: https://reviews.llvm.org/D27632
llvm-svn: 289922
Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there.
Reviewers: zturner, labath, abidh
Subscribers: ki.stfu, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27759
llvm-svn: 289821
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
Summary:
Communication classes use the Timeout<> class to specify the timeout. Listener
class was converted to chrono some time ago, but it used a different meaning for
a timeout of zero (Listener: infinite wait, Communication: no wait). Instead,
Listener provided separate functions which performed a non-blocking event read.
This converts the Listener class to the new Timeout class, to improve
consistency. It also allows us to get merge the different GetNextEvent*** and
WaitForEvent*** functions into one. No functional change intended.
Reviewers: jingham, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D27136
llvm-svn: 288238
Summary:
This class is unused, and since the StringRef refactor, it does not even
implement the Connection interface.
Reviewers: clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27134
llvm-svn: 288117
The conditional expression is ambiguous there, so help it by explicitly casting.
This will go away once we use chrono all the way down.
llvm-svn: 287921
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 concludes the changes I originally tried to make and then
had to back out. This way if anything is still broken, it
should be easier to bisect it back to a more specific changeset.
llvm-svn: 287367
The scanning algorithm had a few little subtleties that I
overlooked, but this patch should fix everything.
I still haven't changed the function to take a StringRef since
that has some trickle down effect and is mostly mechanical,
I just wanted to get the tricky part as isolated as possible.
llvm-svn: 287354
This argument was only used in one place in the codebase, and
it was in a non-critical log statement and can be easily
substituted for an equally meaningful field instead. The
payoff of computing this value is not worth the added
complexity.
llvm-svn: 287315
Apparently these two enormous functions were dead. Which is
good, since one was largely a copy of another function with
only a few minor tweaks.
llvm-svn: 287308
Originally I converted this entire function and all dependents
to use StringRef, but there were some test failures that
were tricky to track down, as this is a complicated function.
So I'm starting over, this time in smaller increments.
llvm-svn: 287307
In the process, found some functions that were duplicates of
existing StringRef member functions. So deleted those functions
and used the StringRef functions instead.
llvm-svn: 287279
This was a bit tricky, especially for things like
OptionValueArray and OptionValueDictionary since they do some
funky string parsing. Rather than try to re-write line-by-line
I tried to make the StringRef usage idiomatic, even though
it meant often re-writing from scratch large blocks of code
in a different way while keeping true to the original intent.
The finished code is a big improvement though, and often much
shorter than the original code. All tests and unit tests
pass on Windows and Linux.
llvm-svn: 287242
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 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
Summary:
The only interesting part here is that TimePoint and TimeValue have different
natural string representations, which affects "target modules list" output. It
is now "2016-07-09 04:02:21.000000000", whereas previously in was
"Sat Jul 9 04:02:21 2016". I wanted to check if we're OK with that.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26275
llvm-svn: 286349
I added a "thread-stop-format" to distinguish between the form
that is just the thread info (since the stop printing immediately prints
the frame info) and one with more frame 0 info - which is useful for
"thread list" and the like.
I also added a frame.no-debug boolean to the format entities so you can
print frame information differently between frames with source info and those
without.
This closes https://reviews.llvm.org/D26383.
<rdar://problem/28273697>
llvm-svn: 286288
This makes the logic easier to follow and also propagates
StringRef up to the API boundary, which is necessary for
making higher up StringRef API changes.
Differential Revision: https://reviews.llvm.org/D26325
llvm-svn: 286204
Summary:
While removing TimeValue from this class I noticed a lot of room for small
simplifications here. Main are:
- instead of complicated start-stop dances to compute own time, each Timer
just starts the timer once, and keeps track of the durations of child
timers. Then the own time can be computed at the end by subtracting the two
values.
- remove double accounting in TimerStack - the stack object already knows the
number of timers.
The interface does not lend itself well to unit testing, but I have added a
couple of tests which can (and did) catch any obvious errors.
Reviewers: tberghammer, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D26243
llvm-svn: 285890
Summary:
The only usage there was in GetModificationTime(). I also took the opportunity
to move this function from FileSpec to the FileSystem class - since we are
using FileSpecs to also represent remote files for which we cannot (easily)
retrieve modification time, it makes sense to make the decision to get the
modification time more explicit.
The new function returns a llvm::sys::TimePoint<>. To aid the transition
from TimeValue, I have added a constructor to it which enables implicit
conversion from a time_point.
Reviewers: zturner, clayborg
Subscribers: mehdi_amini, tberghammer, danalbert, beanz, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D25392
llvm-svn: 285702
This is better for a number of reasons. Mostly style, but also:
1) Signed-unsigned comparison warnings disappear since there is
no loop index.
2) Iterating with the range-for style gives you back an entry
that has more than just a const char*, so it's more efficient
and more useful.
3) Makes code safter since the type system enforces that it's
impossible to index out of bounds.
llvm-svn: 283413
There were a number of issues with the Args class preventing
efficient use of strings and incoporating LLVM's StringRef class.
The two biggest were:
1. Backing memory stored in a std::string, so we would frequently
have to use const_cast to get a mutable buffer for passing to
various low level APIs.
2. backing std::strings stored in a std::list, which doesn't
provide random access.
I wanted to solve these two issues so that we could provide
StringRef access to the underlying arguments, and also a way
to provide range-based access to the underlying argument array
while still providing convenient c-style access via an argv style
const char**.
The solution here is to store arguments in a single "entry" class
which contains the backing memory, a StringRef with precomputed
length, and the quote char. The backing memory is a manually
allocated const char* so that it is not invalidated when the
container is resized, and there is a separate argv array provided
for c-style access.
Differential revision: https://reviews.llvm.org/D25099
llvm-svn: 283157
Summary: The code added in svn r264332 causes "(lldb) " to be printed in the
middle of program console output. This fix restores the behavior for non-Windows
platforms to before the patch.
Reviewers: ted, zturner, clayborg
Subscribers: amccarth, lldb-commits
Differential Revision: http://reviews.llvm.org/D25137
llvm-svn: 283031
The test exposed a bug in the StructuredData Serialization code, which did not
escape the backslash properly. This manifested itself as windows breakpoint
serialization roundtrip test not succeeding (as windows paths included
backslashes).
llvm-svn: 282167
This change introduces optional marking of the column within a source
line where a thread is stopped. This marking will show up when the
source code for a thread stop is displayed, when the debug info
knows the column information, and if the optional column marking is
enabled.
There are two separate methods for handling the marking of the stop
column:
* via ANSI terminal codes, which are added inline to the source line
display. The default ANSI mark-up is to underline the column.
* via a pure text-based caret that is added in the appropriate column
in a newly-inserted blank line underneath the source line in
question.
There are some new options that control how this all works.
* settings set stop-show-column
This takes one of 4 values:
* ansi-or-caret: use the ANSI terminal code mechanism if LLDB
is running with color enabled; if not, use the caret-based,
pure text method (see the "caret" mode below).
* ansi: only use the ANSI terminal code mechanism to highlight
the stop line. If LLDB is running with color disabled, no
stop column marking will occur.
* caret: only use the pure text caret method, which introduces
a newly-inserted line underneath the current line, where
the only character in the new line is a caret that highlights
the stop column in question.
* none: no stop column marking will be attempted.
* settings set stop-show-column-ansi-prefix
This is a text format that indicates the ANSI formatting
code to insert into the stream immediately preceding the
column where the stop column character will be marked up.
It defaults to ${ansi.underline}; however, it can contain
any valid LLDB format codes, e.g.
${ansi.fg.red}${ansi.bold}${ansi.underline}
* settings set stop-show-column-ansi-suffix
This is the text format that specifies the ANSI terminal
codes to end the markup that was started with the prefix
described above. It defaults to: ${ansi.normal}. This
should be sufficient for the common cases.
Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!)
differential review: https://reviews.llvm.org/D20835
reviewers: clayborg, jingham
llvm-svn: 282105
r282079 converted the regular expression interface to accept
and return StringRefs instead of char pointers. In one case
a null pointer check was converted to an empty string check,
but this was an incorrect conversion because an empty string
is a valid regular expression. Removing this check should
fix the test failures.
llvm-svn: 282090
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
This makes the code easier to grok, and since this is a very low
level function it also is very helpful to have this take a StringRef
since it means anyone higher up the chain who has a StringRef would
have to first convert it to a null-terminated string. This way it
can work equally well with StringRefs or const char*'s, which will
enable the conversion of higher up functions to StringRef.
Tested on Windows, Linux, and OSX and saw no regressions.
llvm-svn: 281642
Moved the guts of the code from CommandObjectBreakpoint to Target (should
have done it that way in the first place.) Added an SBBreakpointList class
so there's a way to specify which breakpoints to serialize and to report the
deserialized breakpoints.
<rdar://problem/12611863>
llvm-svn: 281520
I'm was trying to do some cleanup and code modernization and in
doing so I needed to change ParseMachCPUDashSubtypeTriple to take
a StringRef. To ensure I don't break anything, I'm adding some
unit tests for this function. As a side benefit, this also expands
test coverage of this function to all platforms, since in general
this code would rarely be exercised on non Mac platforms, and never
in the test suite.
llvm-svn: 281387
Plumb unique_ptrs<> all the way through the baton interface.
NFC, this is a minor improvement to remove the possibility of an
accidental pointer ownership issue.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D24495
llvm-svn: 281360
Still to come:
1) SB API's
2) Testcases
3) Loose ends:
a) serialize Thread options
b) serialize Exception resolvers
4) "break list --file" should list breakpoints contained in a file and
"break read -f 1 3 5" should then read in only those breakpoints.
<rdar://problem/12611863>
llvm-svn: 281273
Summary:
It fixes the following compile warnings:
1. '0' flag ignored with precision and ‘%d’ gnu_printf format
2. enumeral and non-enumeral type in conditional expression
3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ...
4. enumeration value ‘...’ not handled in switch
5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers
6. extra ‘;’
7. comparison between signed and unsigned integer expressions
8. variable ‘register_operand’ set but not used
9. control reaches end of non-void function
Reviewers: jingham, emaste, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24331
llvm-svn: 281191
mode in lldb works. I've been discussing this with Jim Ingham,
Greg Clayton, and Kate Stone for the past week or two.
Previously lldb would print three source lines (centered on the
line table entry line for the current line) followed by the assembly.
It would print the context information (module`function + offset)
before those three lines of source.
Now lldb will print up to two lines before/after the line table
entry. It prints two '*' characters for the line table line to
make it clear what line is showing assembly. There is one line of
whitespace before/after the source lines so the separation between
source & assembly is clearer. I don't print the context line
(module`function + offset). I stop printing context lines if it's
a different line table entry, or if it's a source line I've already
printed as context to another source line. If I have two line table
entries one after another for the same source line (I get these often
with clang - with different column information in them), I only print
the source line once.
I'm also using the target.process.thread.step-avoid-regexp setting
(which keeps you from stepping into STL functions that have been inlined
into your own code) and avoid printing any source lines from functions
that match that regexp.
When lldb disassembles into a new function, it will try to find the
declaration line # for the function and print all of the source lines
between the decl and the first line table entry (usually a { curly brace)
so we have a good chance of including the arguments, at least with the
debug info emitted by clang.
Finally, the # of source lines of context to show has been separated
from whether we're doing mixed source & assembly or not. Previously
specifying 0 lines of context would turn off mixed source & assembly.
I think there's room for improvement, and maybe some bugs I haven't
found yet, but it's in good enough shape to upstream and iterate at
this point.
I'm not sure how best to indicate which source line is the actual line
table # versus context lines. I'm using '**' right now. Both Kate
and Greg had the initial idea to reuse '->' (normally used to indicate
"currently executing source line") - I tried it but I wasn't thrilled,
I'm too used to the established meaning of ->.
Greg had the interesting idea of avoiding context source lines only
in two line table entries in the same source file. So we'd print
two lines before & after a source line, and then the next line table
entry (if it was on the next source line after those two context lines)
we'd display only the following two lines -- the previous two had just
been printed. If an inline source line was printed between these two,
though, we'd print the context lines for both of them. It's an
interesting idea, and I want to see how it works with both -O0 and -O3
codegen where we have different amounts of inlining.
<rdar://problem/27961419>
llvm-svn: 280906
*** 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
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
std::atomic<uint64_t> requires 64-bit alignment in order to
guarantee atomicity. Normally the compiler is pretty good about
aligning types, but an exception to this is when the type is
passed by value as a function parameter. In this case, if your
stack is 4-byte aligned, most modern compilers (including clang
as of LLVM 4.0) fail to align the type, rendering the atomicity
ineffective.
A deeper investigation of the class's implementation suggests
that the use of atomic was in vain anyway, because if the class
were to be shared amongst multiple threads, there were already
other data races present, and that the proper way to ensure
thread-safe access to this data would be to use a mutex from a
higher level.
Since the std::atomic was not serving its intended purpose anyway,
and since the presence of it generates compiler errors on some
platforms that cannot be workaround, we remove std::atomic from
Address here. Although unlikely, if data races do resurface
the proper fix should involve a mutex from a higher level, or an
attempt to limit the Address's access to a single thread.
llvm-svn: 279994
Summary:
Previously the builting demangler was on for platforms that explicitly set a flag by modifying
Mangled.cpp (windows, freebsd). The Xcode build always used builtin demangler by passing a
compiler flag. This adds a cmake flag (defaulting to ON) to configure the demangling library used
at build time. The flag is only available on non-windows platforms as there the system demangler
is not present (in the form we're trying to use it, at least).
The impact of this change is:
- linux: switches to the builtin demangler
- freebsd, windows: NFC (I hope)
- netbsd: switches to the builtin demangler
- osx cmake build: switches to the builtin demangler (matching the XCode build)
The main motivation for this is the cross-platform case, where it should bring more consistency
by removing the dependency on the host demangler (which can be completely unrelated to the debug
target).
Reviewers: zturner, emaste, krytarowski
Subscribers: emaste, clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D23830
llvm-svn: 279808
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
Jim Ingham