Todd added this empty readline module to workaround an issue with an old
version of Python on Ubuntu in 2014 (18841). In the meantime, libedit
seems to have fixed the underlying issue, and indeed, I wasn't able to
reproduce this.
Differential revision: https://reviews.llvm.org/D59972
llvm-svn: 357277
For = operators for lists that have mutexes, we were either
just taking the locks sequentially or hand-rolling a trick
to try to avoid lock inversion. Use the std::lock mechanism
for this instead.
Differential Revision: https://reviews.llvm.org/D59957
llvm-svn: 357276
It was making a list of a certain size but not always filling in that
many elements, which would lead to a crash iterating over the list.
Differential Revision: https://reviews.llvm.org/D59913
llvm-svn: 357207
For a single char argument, find_first_of is equal to find and
find_last_of is equal to rfind. While playing around with the plugin
stuff this caused an export failure because it always got inlined except
once, which resulted in an undefined symbol.
llvm-svn: 357198
the collection lock before we iterate over the owners calling ShouldStop.
BreakpointSite::ShouldStop can do a lot of work, and might by chance hit the same breakpoint
site again on another thread. So instead of holding the site's owners lock
while iterating over them calling ShouldStop, I make a local copy of the list, drop the lock
and then iterate over the copy calling BreakpointLocation::ShouldStop.
It's actually quite difficult to make this cause problems because usually all the
action happens on the private state thread, and the lock is recursive.
I have a report where some code hit the ASAN error breakpoint, went to
compile the ASAN error gathering expression, in the course of compiling
that we went to fetch the ObjC runtime data, but the state of the program
was such that the ObjC runtime grubbing function triggered an ASAN error and
we were executing that function on another thread.
I couldn't figure out a way to reproduce that situation in a test. But this is an
NFC change anyway, it just makes the locking strategy more narrowly focused.
<rdar://problem/49074093>
llvm-svn: 357141
Currently, only ClangASTContext knows about PDBASTParser. Eventually
we want the TypeSystem to have getters/setters for the base parser
and then have the TypeSystem subclasses know about the proper
PDBASTParser subclasses. This is similar to how DWARFASTParsers work.
llvm-svn: 357131
Summary:
An TranslationUnitDecl was being brought in from the clang::ASTContext
which required clang specific code to exist in SymbolFilePDB.
Since it was unused we can just get rid of it along with the clang
specific code.
Reviewers: rnk, zturner, compnerd
Reviewed By: compnerd
Subscribers: jdoerfert
Differential Revision: https://reviews.llvm.org/D59804
llvm-svn: 357113
This re-commits r354263, which was because it uncovered with handling of
modules with empty (zero) UUIDs. This would cause us to treat two
modules as intentical even though they were not. This caused an assert
in PlaceholderObjectFile::SetLoadAddress to fire, because we were trying
to load the module twice even though it was designed to be only loaded
at a specific address. (The same problem also existed with the previous
implementation, but it had no asserts to warn us about this.) These
issues have now been fixed in r356896.
windows bot. The issue there was that ObjectFilePECOFF vended its base
address through the incorrect interface. SymbolFilePDB depended on that,
which lead to assertion failures when SymbolFilePDB was attempting to
use the placeholder object files as a base. This has been fixed in
r354258
The original commit message was:
The reason this wasn't working was that ProcessMinidump was creating odd
object-file-less modules, and SymbolFileBreakpad required the module to
have an associated object file because it needed to get its base
address.
This fixes that by introducing a PlaceholderObjectFile to serve as a
dummy object file. The general idea for this is taken from D55142, but
I've reworked it a bit to avoid the need for the PlaceholderModule
class. Now that we have an object file, our modules are sufficiently
similar to regular modules that we can use the regular Module class
almost out of the box -- the only thing I needed to tweak was the
Module::CreateModuleFromObjectFile functon to set the module's FileSpec
in addition to it's architecture. This wasn't needed for ObjectFileJIT
(the other user of CreateModuleFromObjectFile), but it shouldn't hurt it
either, and the change seems like a straightforward extension of this
function.
Reviewers: clayborg, lemo, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D57751
llvm-svn: 357060
This is diagnosed by gcc-8. The ValueType struct already has a default
constructor which performs zero-initialization, so we can just call that
instead of using memset.
llvm-svn: 357056
Summary:
gcc diagnoses this as "array subscript 63 is above array bounds of
'RegisterContextDarwin_arm64::VReg [32]'".
The correct fix seems to be subtracting the fpu register base index, but
I have no way of verifying that this actually works.
Reviewers: jasonmolenda
Subscribers: javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D59495
llvm-svn: 357055
Summary:
Instead of assuming that the language is C++ instead check the compunit
for the language it received from the debug info.
Subscribers: aprantl, jdoerfert
Differential Revision: https://reviews.llvm.org/D59805
llvm-svn: 357044
Remove CompilerInstance::VirtualFileSystem and
CompilerInstance::setVirtualFileSystem, instead relying on the VFS in
the FileManager. CompilerInstance and its clients already went to some
trouble to make these match. Now they are guaranteed to match.
As part of this, I added a VFS parameter (defaults to nullptr) to
CompilerInstance::createFileManager, to avoid repeating construction
logic in clients that just wanted to customize the VFS.
https://reviews.llvm.org/D59377
llvm-svn: 357037
Summary:
In the current state, 'ninja check-lldb' runs the lldb-vscode tests, but it
won't rebuild lldb-vscode if any of its sources has changed. This is very
confusing when you fix something and the tests keep failing, or vice versa.
Reviewers: clayborg
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59828
llvm-svn: 357016
Summary:
After D59297, the TypePair class kind of lost its purpose as it was no
longer a "pair". This finishes the job started in that patch and deletes
the class altogether. All usages have been updated to use CompilerType
class directly.
Reviewers: clayborg, jingham, zturner
Subscribers: mehdi_amini, dexonsmith, jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59414
llvm-svn: 356993
This is the next step in moving the minidump parsing into llvm. I remove
the minidump structures already defined in the llvm Object library and
convert our parser to use those. NFC.
llvm-svn: 356992
The python plugin uses wrappers generated by swig. For the symbols to be
available, we'd need to link against liblldb, which is not an option
because the symbols could conflict with the static library we are
testing. Instead we define the symbols ourselves in the unit test.
llvm-svn: 356971
With the initialization taking place inside the Python script
interpreter, these function no longer need to be public. The exception
is the g_swig_init_callback which is used from the RAII object.
llvm-svn: 356944
Currently LLDB crashes when autocompleting a command that ends with a
backtick because the quote character wasn't handled. This fixes that and
adds a unit test for this function.
Differential revision: https://reviews.llvm.org/D59779
llvm-svn: 356927
At the moment when --repl is passed to lldb it silently ignores any
commands passed via the options below:
--one-line-before-file <command>
Tells the debugger to execute this one-line lldb command before any file provided on the command line has been loaded.
--one-line <command>
Tells the debugger to execute this one-line lldb command after any file provided on the command line has been loaded.
--source-before-file <file>
Tells the debugger to read in and execute the lldb commands in the given file, before any file has been loaded.
--source <file>
Tells the debugger to read in and execute the lldb commands in the given file, after any file has been loaded.
-O <value> Alias for --one-line-before-file
-o <value> Alias for --one-line
-S <value> Alias for --source-before-file
-s <value> Alias for --source
The -O and -S options are quite useful when writing tests for the REPL
though, e.g. to change settings prior to entering REPL mode. This
patch updates the driver to still respect the commands supplied via -O
and -S when passing --repl instead of silently ignoring them. As -s
and -o don't really make sense in REPL mode, commands supplied via
those options are still ignored, but the driver now emits a warning to
make that clear to the user.
Patch by Nathan Hawes!
Differential Revision: https://reviews.llvm.org/D59681
llvm-svn: 356911
This patch begins the process of migrating the "minidump" plugin to the
minidump parser in llvm. The llvm parser is not fully finished yet, but
even now, a lot of things can be switched over. The gradual migration
process will allow us to easier detect if things break than doing a big
one-step migration. Doing it early will allow us to make sure that the
llvm parser fits the use case that we need in lldb.
In this patch I start with the various minidump constants, which have
their llvm equivalent. It doesn't contain any functional changes. The
diff just reflects the different naming of things in llvm.
llvm-svn: 356898
The changes were reverted due to ubsan errors (unaligned accesses). Here
I fix those errors by first copying the data into aligned storage.
Besides fixing alignment issues, this also fixes reading of minidump
strings on big-endian systems.
llvm-svn: 356896
This fixes the flakiness of the GDB remote reproducer during replay. It
was caused by a combination sending one ACK to many from the replay
server and the code that "flushes" any queued GDB remote packets in
GDBRemoteCommunicationClient::HandshakeWithServer.
The spurious ACK was the result of combining both implicit and explicit
handling of ACKs in the replay server. The handshake consists of an ACK
followed by an QStartNoAckMode. As long as we haven't seen any
QStartNoAckMode, we were sending implicit acknowledgments. So the first
ACK got acknowledged twice, once implicitly, and once as part of the
replay.
The reason we didn't notice this was the code in HandshakeWithServer
that "waits for any responses that might have been queued up in the
remote GDB server and flush them all". A 10ms timeout is used to move on
when no packets are left. If the second ACK didn't make it within those
10ms, all packets were offset by one.
llvm-svn: 356825
Summary:
For the only version of Python actually supported on Darwin.
<rdar://problem/40961425>
Reviewers: jingham, friss, JDevlieghere, aprantl, jasonmolenda
Subscribers: jdoerfert, llvm-commits, lldb-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59719
llvm-svn: 356816
This reverts the following two commits:
Revert "Extend r356573 (minidump UUID handling) to cover elf build-ids too"
Revert "Fix UUID decoding from minidump files"
Greg's original commit broke the sanitizer bot which has been red for
several days now.
http://green.lab.llvm.org/green/view/LLDB/job/lldb-sanitized/
llvm-svn: 356806
This reverts commit r356682 because it breaks the DWO flavours of some
tests:
lldb-Suite :: lang/c/const_variables/TestConstVariables.py
lldb-Suite :: lang/c/local_variables/TestLocalVariables.py
lldb-Suite :: lang/c/vla/TestVLA.py
llvm-svn: 356773
Jonas Devlieghere