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
LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support
for DWARF64 is only partial, and if enabled appears to also not work.
Finally, it's untested. Removing this makes merging LLVM and
LLDB's DWARF parsing implementations simpler.
Differential Revision: https://reviews.llvm.org/D59235
llvm-svn: 355975
This is a very thin wrapper over a std::vector<DWARFDIE> and does
not seem to provide any real value over just using a container
directly.
Differential Revision: https://reviews.llvm.org/D59165
llvm-svn: 355974
This is not used outside of the private implementation of the class,
so hiding in the implementation file is a nice way of simplifying
the external interface.
Differential Revision: https://reviews.llvm.org/D59164
llvm-svn: 355973
darwin kernel debug session.
Originally, the kext name & uuid were emitted in the middle of the
kext-loading period's. Last week I decided to try not printing
any details about kexts that failed to load, only printing a summary
of how many failed to load.
This time I'm print different progress characters depending on whether
the kext loaded or not ("-" for not), then at the end I will print a
summary of how many kexts failed to load and a sorted list of the
kexts with the bundle ID and the uuid. It's a lot more readable.
<rdar://problem/48654569>
llvm-svn: 355958
There's a single report of a crash coming from this current_sp being NULL. I don't
have a repro case, and I couldn't get it to happen by hand-corrupting a list. We
always get an error instead. So I don't have a test case. But checking for null
is clearly right here.
<rdar://problem/48503320>
llvm-svn: 355957
ICF can cause multiple symbols to start at the same virtual address.
I plan to handle this shortly, but I wanted to correct the comment for
now.
Deleted an obsolete comment about adjusting the offset for the magic
number at the beginning of the debug info stream. This adjustment is
handled at a lower level now.
llvm-svn: 355943
Yesterday I noticed a reproducer test failing after making a local
change. Removing the reproducer directory solved the issue. Add a test
case that detects this.
llvm-svn: 355941
Zachary Turner