Move SBRegistry method registrations from SBReproducer.cpp into files
declaring the individual APIs, in order to reduce the memory consumption
during build and improve maintainability. The current humongous
SBRegistry constructor exhausts all memory on a NetBSD system with 4G
RAM + 4G swap, therefore making it impossible to build LLDB.
Differential Revision: https://reviews.llvm.org/D59427
llvm-svn: 356481
These log statements have questionable value, and hinder the effort
of separating the high and low level DWARF parsing interfaces inside
of LLDB. Removing them for now, and if/when we need such log statements
again in the future, we can add them back (if possible) or introduce a
mechanism for logging from the low-level interface in such a way that it
isn't coupled to the high level interface.
Differential Revision: https://reviews.llvm.org/D59498
llvm-svn: 356469
This is a new warning which started appearing as of gcc-8. The Opcode
class has a non-trivial constructor, so the idea of the warning is that
code should use that to initialize the object instead of using memset
(which can perturb class invariants set up by the constructor). In this
case, the Opcode default constructor was already clearing the object's
fields so we can just drop the memset call.
While I'm touching the EmulateInstruction constructor, I also move the
initialization of other members into the class declaration.
llvm-svn: 356459
Summary:
This is a preparatory step to enable adding of unwind plans by symbol
file plugins.
Although at the surface it seems that currently symbol files have
nothing to do with unwinding, this isn't entirely correct even now. The
mere act of adding a symbol file can have the effect of making more
sections (typically .debug_frame) available to the unwinding machinery,
so that it can have more unwind strategies to choose from.
Up until now, we've had a bug, which went largely unnoticed, where
unwind info in the manually added symbols files (target symbols add) was
being ignored during unwinding. Reinitializing the UnwindTable fixes
that bug too.
Reviewers: clayborg, jasonmolenda, alexshap
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58347
llvm-svn: 356361
This continues the work of introducing Error and Expected into
the DWARF parsing interfaces, this time for the DWARFCompileUnit
and DWARFDebugAranges classes.
Differential Revision: https://reviews.llvm.org/D59381
llvm-svn: 356278
The package name is LibEdit, so we should use that name in the call to
find_package_handle_standard_args. Failing to do so results in the
standard_args (such as the one telling us whether REQUIRED was used in
the find_package invocation) not being handled.
llvm-svn: 356263
Summary:
As discussed in the review of D59217, this member is unnecessary since
always the first thing we do is convert it to a CompilerType.
This opens up possibilities for further cleanups (e.g. the whole
TypePair class now loses purpose, since we can just pass around
CompilerType everywhere), but I did not want to do that yet, because I
am not sure if this will not introduce breakages in some of the
platforms/configurations that I am not testing on.
Reviewers: clayborg, zturner, jingham
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59297
llvm-svn: 356262
SBError::GetCString() returns a pointer to a string owned by the SBError
object. The code here was calling GetCString on a temporary and using
the returned pointer after the temporary was destroyed.
Differential Revision: https://reviews.llvm.org/D59400
llvm-svn: 356227
The goal here is to improve our error handling and error recovery while
parsing DWARF, while at the same time getting us closer to being able to
merge LLDB's DWARF parser with LLVM's. To this end, I've udpated several
of the low-level parsing functions in LLDB to return llvm::Error and
llvm::Expected.
For now, this only updates LLDB parsing functions and not LLVM. In some
ways, this actually gets us *farther* from parity with the two
interfaces, because prior to this patch, at least the parsing interfaces
were the same (i.e. they all just returned bools, and now with this
patch they're diverging). But, I chose to do this for two primary
reasons.
LLDB has error logging code engrained deep within some of its parsing
functions. We don't want to lose this logging information, but obviously
LLVM has no logging mechanism at all. So if we're to merge the
interfaces, we have to find a way to still allow LLDB to properly report
parsing errors while not having the reporting code be inside of LLVM.
LLDB (and indeed, LLVM) overload the meaning of the false return value
from all of these extraction functions to mean both "We reached the null
entry at the end of a list of items, therefore everything was
successful" as well as "something bad and unrecoverable happened during
parsing". So you would have a lot code that would do something like:
while (foo.extract(...)) {
...
}
But when the loop stops, why did it stop? Did it stop because it
finished parsing, or because there was an error? Because of this, in
some cases we don't always know whether it is ok to proceed, or how to
proceed, but we were doing it anyway.
In this patch, I solve the second problem by introducing an
enumeration called DWARFEnumState which has two values MoreItems and
Complete. Both of these indicate success, but the latter indicates
that we reached the null entry. Then, I return this value instead of
bool, and convey parsing failure separately.
To solve the first problem (and convey parsing failure) these
functions now return either llvm::Error or llvm::Expected<DWARFEnumState>.
Having this extra bit of information allows us to properly convey all 3 of
"error, bail out", "success, call this function again", and "success,
don't call this function again".
In subsequent patches I plan to extend this pattern to the rest of the
parsing interfaces, which will ultimately get all of the log statements
and error reporting out of the low level parsing code and into the high
level parsing code (e.g. SymbolFileDWARF, DWARFASTParserClang, etc).
Eventually, these same changes will have to be backported to LLVM's
DWARF parser, but diverging in the short term is the easiest way to
converge in the long term.
Differential Revision: https://reviews.llvm.org/D59370
llvm-svn: 356190
Summary:
Makes the code a bit safer in the unlikely situation that we don't get a ClangUserExpression
when doing code completion.
Reviewers: aprantl, jingham
Reviewed By: aprantl
Subscribers: labath, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59359
llvm-svn: 356174
This fixes a data race uncovered by tsan during destruction of the
GDBRemoteReplay server. The solution is to lock the thread state mutex
when receiving packets.
llvm-svn: 356168
If an invalid program is specified, lldb-vscode will send back a
response with "success" = false, but then will continue executing the
rest of request_launch(), try to launch the program anyway and try to
send another response (possibly using the `response` object after it was
moved).
This change adds a return statement so we stop executing the handler
after producing the first failing response.
Differential Revision: https://reviews.llvm.org/D59340
llvm-svn: 356110
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule a
bit so that we only read the binaries out of memory once we've
determined that we can find a real binary on the local system.
Previously, lldb would read all of the kext binaries out of memory
and then determine if it had the local copy. The kext table gives
us most the information we need (address, name, uuid) so lldb only
needs the actual in-memory load commands when it comes time to set
the section load addresses. Delay reading until that point for all
the kexts.
NFC; doing the operations in a different order.
<rdar://problem/41181173>
llvm-svn: 356108
Python 3 default encoding is utf-8, so taking random bytes and
interpreting them as a string might result in invalid unicode sequences.
As the only thing we care about here is that the formatter shows the
elements of the underyling array, relax the string matching (this is
good enough as all the elements are distinct so they resolve to different
strings).
llvm-svn: 356096
Summary:
In my next step at cleaning up modify-python-lldb.py, I started focusing
on equality comparison. To my surprise, I found out that both python and
c++ versions of the SBType class implement equality comparison, but each
one does it differently. While the python version was implemented in
terms of type name equality, the C++ one used a deep comparison on the
underlying objects.
Removing the python version caused one test to fail (TestTypeList). This
happened because the c++ version of operator== boiled down to
TypePair::operator==, which contains two items: the compiler_type and
type_sp. In this case, the compiler_type was identical, but one of the
objects had the type_sp field unset.
I tried fixing the code so that both objects keep their type_sp member,
but it wasn't easy, because there are so many operations which just work
with the CompilerType types, and so any operation on the SBType (the
test in question was doing GetPointeeType on the type of one variable
and expecting it to match the type of another variable), cause that
second member to be lost.
So instead, here I relax the equality comparison on the TypePair
class. Now, this class ignores the type_sp for the purposes of
comparison, and uses the CompilerType only. This seems reasonable, as
each TypeSP is able to convert itself to a CompilerType.
Reviewers: clayborg, aprantl, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59217
llvm-svn: 356048
Given this was under trace, it can just be removed. If somebody
ever needs to debug this testcase again and print the data, they
can add a new statement.
llvm-svn: 355999
This patch adds an XCOFF triple object format type into LLVM.
This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform.
Differential Revision: https://reviews.llvm.org/D58930
llvm-svn: 355989
