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
