| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59606
llvm-svn: 356703
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59580
llvm-svn: 356695
|
|
|
|
|
|
|
|
|
| |
This is mostly mechanical, and just moves the remaining non-DWO
related sections over to DWARFContext.
Differential Revision: https://reviews.llvm.org/D59611
llvm-svn: 356682
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59588
llvm-svn: 356673
|
|
|
|
|
|
|
|
|
| |
When the output of map is not used, using a list comprehension or an explicit
call to list looks awkward.
Differential Revision: https://reviews.llvm.org/D59587
llvm-svn: 356672
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59585
llvm-svn: 356671
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59583
llvm-svn: 356670
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59579
llvm-svn: 356647
|
|
|
|
|
|
|
|
| |
On Linux, a QEnvironment packet is sent for every environment variable.
This breaks replay when the number of environment variables is different
then during capture. The solution is to always reply with OK.
llvm-svn: 356643
|
|
|
|
|
|
|
|
| |
Make debugging of the GDB remote packet aspect of reproducers easier by
logging both requests and replies. This enables some sanity checking
during replay.
llvm-svn: 356638
|
|
|
|
|
|
|
|
| |
if LOG_PROCESS is enabled or if there was an error making that call.
<rdar://problem/49036508>
llvm-svn: 356626
|
|
|
|
| |
llvm-svn: 356625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM's DWARF parsing library has a class called DWARFContext which holds
all of the various DWARF data sections and lots of other information.
LLDB's on the other hand stores all of this directly in SymbolFileDWARF
/ SymbolFileDWARFDwo and passes this interface around through the
parsing library. Obviously this is incompatible with a world where the
low level interface does not depend on the high level interface, so we
need to move towards a model similar to LLVM's - i.e. all of the context
needed for low level parsing should be in a single class, and that class
gets passed around.
This patch is a small incremental step towards achieving this. The
interface and internals deviate from LLVM's for technical reasons, but
the high level idea is the same. The goal is, eventually, to remove all
occurrences of SymbolFileDWARF from the low level parsing code.
For now I've chosen a very simple section - the .debug_aranges section
to move into DWARFContext while leaving everything else unchanged. In
the short term this is a bit confusing because now the information you
need might come from either of 2 different locations. But it's a huge
refactor to do this all at once and runs a much higher risk of breaking
things. So I think it would be wise to do this in very small pieces.
TL;DR - No functional change
Differential Revision: https://reviews.llvm.org/D59562
llvm-svn: 356612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor is it documented.
Reviewers: balazske, martong, a.sidorin, shafik
Reviewed By: balazske, martong
Subscribers: rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59595
llvm-svn: 356592
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes:
UUIDs now don't include the age field from a PDB70 when the age is zero. Prior to this they would incorrectly contain the zero age which stopped us from being able to match up the UUID with real files.
UUIDs for Apple targets get the first 32 bit value and next two 16 bit values swapped. Breakpad incorrectly swaps these values when it creates darwin minidump files, so this must be undone so we can match up symbol files with the minidump modules.
UUIDs that are all zeroes are treated as invalid UUIDs. Breakpad will always save out a UUID, even if one wasn't available. This caused all files that have UUID values of zero to be uniqued to the first module that had a zero UUID. We now don't fill in the UUID if it is all zeroes.
Added tests for PDB70 and ELF build ID based CvRecords.
Differential Revision: https://reviews.llvm.org/D59433
llvm-svn: 356573
|
|
|
|
|
|
|
|
| |
All of this is code that is unreferenced. Removing as much of
this as possible makes it more easy to determine what functionality
is missing and/or shared between LLVM and LLDB's DWARF interfaces.
llvm-svn: 356509
|
|
|
|
| |
llvm-svn: 356495
|
|
|
|
|
|
|
|
|
|
| |
Most of these are Dump functions that are never called, but there
is one instance of entire unused classes (DWARFDebugMacinfo and
DWARFDebugMacinfoEntry) which are also unreferenced in the codebase).
Differential Revision: https://reviews.llvm.org/D59276
llvm-svn: 356490
|
|
|
|
| |
llvm-svn: 356487
|
|
|
|
| |
llvm-svn: 356486
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
rdar://problem/48883558
Differential Revision: https://reviews.llvm.org/D59524
llvm-svn: 356462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EmulateInstruction
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
|
|
|
|
|
|
|
|
| |
Aarch32 Cortex-M target processor debugging.
<rdar://problem/48448564>
llvm-svn: 356416
|
|
|
|
|
|
|
| |
LLVM installed llvm-lit with a .py suffix on windows. Let's match that
behavior here.
llvm-svn: 356412
|
|
|
|
| |
llvm-svn: 356401
|
|
|
|
|
|
| |
Test hangs under heavy load.
llvm-svn: 356379
|
|
|
|
|
|
| |
gcc-8 diagnoses these.
llvm-svn: 356378
|
|
|
|
|
|
|
| |
Use floor-division for consistentcy across python versions. This fixes a
couple of libstdc++ data formatter tests.
llvm-svn: 356377
|
|
|
|
|
|
| |
s/iteritems/items
llvm-svn: 356370
|
|
|
|
|
|
| |
These warnings start to get emitted with gcc-8.
llvm-svn: 356362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Treat a null tag as an error.
llvm-svn: 356284
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rdar://problem/48889580
llvm-svn: 356275
|
|
|
|
| |
llvm-svn: 356271
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
And DataVisualization. One step closer.
llvm-svn: 356225
|
|
|
|
| |
llvm-svn: 356210
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
I stumbled upon this while removing LLDB_DISABLE_PYTHON when
not needed.
llvm-svn: 356176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
While we don't have a bot, I'm testing by hand that this configuration
compiles. We'll probably set up one once I'm done flensing.
llvm-svn: 356171
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 356160
|
|
|
|
|
|
| |
to test binaries.
llvm-svn: 356113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|