Summary:
One small step in my long running quest to improve python exception handling in
LLDB. Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78462
Several SB API functions return strings using (char*, size_t) output
arguments. During capture, we serialize an empty string for the char*
because the memory can be uninitialized.
During active replay, we have custom replay redirects that ensure that
we don't override the buffer from which we're reading, but rather write
to a buffer on the heap with the given length. This is sufficient for
the active reproducer use case, where we only care about the side
effects of the API calls, not the values actually returned.
This approach does not not work for passive replay because here we
ignore all the incoming arguments, and re-execute the current function
with the arguments deserialized from the reproducer. This means that
these function will update the deserialized copy of the arguments,
rather than whatever was passed in by the SWIG wrapper.
To solve this problem, this patch extends the reproducer instrumentation
to handle this special case for passive replay. We nog ignore the
replayer in the registry and the incoming char pointer, and instead
reinvoke the current method on the deserialized class, and populate the
output argument.
Differential revision: https://reviews.llvm.org/D77759
This wasn't a great idea to begin with, as you can't really rely on the
implementation, but since it also doesn't work with MSVC I've just made
the ctors public.
Support passive replay as proposed in the RFC [1] on lldb-dev and
described in more detail on the lldb website [2].
This patch extends the LLDB_RECORD macros to re-invoke the current
function with arguments deserialized from the reproducer. This relies on
the function being called in the exact same order as during replay. It
uses the same mechanism to toggle the API boundary as during recording,
which guarantees that only boundary crossing calls are replayed.
Another major change is that before this patch we could ignore the
result of an API call, because we only cared about the observable
behavior. Now we need to be able to return the replayed result to the
SWIG bindings.
We reuse a lot of the recording infrastructure, which can be a little
confusing. We kept the existing naming to limit the amount of churn, but
might revisit that in a future patch.
[1] http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
[2] https://lldb.llvm.org/resources/reproducers.html
Differential revision: https://reviews.llvm.org/D77602
Summary:
Lookup and subsequent insert was done using uninitialized
FileSpec object, which caused the cache to be a no-op.
Bug: llvm.org/PR45310
Depends on D76804.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: mgorny, jingham, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76805
Fix a bug where UnwindAssemblyInstEmulation would confuse which
register is used to compute the Canonical Frame Address after it
had branched over a mid-function epilogue (where the CFA reg changes
from $fp to $sp in the process of epiloguing). Reinstate the
correct CFA register after we forward the unwind rule for branch
targets. The failure mode was that UnwindAssemblyInstEmulation
would think CFA was set in terms of $sp after one of these epilogues,
and if it sees modifications to $sp after the branch target, it would
change the CFA offset in the unwind rule -- even though the CFA is
defined in terms of $fp and the $sp changes are irrelevant to correct
calculation.
<rdar://problem/60300528>
Differential Revision: https://reviews.llvm.org/D78077
Summary:
Removing the Test prefix from the file name and its usages. The standard is using only Test as a suffix.
This was correctly pointed out in https://reviews.llvm.org/D77444.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77878
The instrumentation unit tests' current implementation uses global
variables to track constructor calls for the instrumented classes during
replay. This is suboptimal because it indirectly relies on how the
reproducer instrumentation is implemented. I found out when adding
support for passive replay and the test broke because we made an extra
(temporary) copy of the instrumented objects.
Additionally, the old approach wasn't very self-explanatory. It took me
a bit of time to understand why we were expecting the number of objects
in the test.
This patch rewrites the test and uses the index-to-object-mapping to
verify the objects created during replay. You can now specify the
expected objects, in order, and whether they should be valid or not. I
find that it makes the tests much easier to understand. More
importantly, this approach is resilient to implementation detail changes
in the instrumentation.
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.
The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
for the event
- Disconnect(): close the connection. This is the only bit that needs to
be in the critical section, and this is to ensure that we don't close
the connection while the synchronizing thread is mucking with it.
Original commit message follows:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
Summary:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
Summary:
This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.
Comprehensive tests are included as well.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77444
This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.
The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.
For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.
rdar://problem/60640017
Differential Revision: https://reviews.llvm.org/D76471
LLDB relies on empty FileSpecs being invalid files, for example, they
don't exists. Currently this assumption does not always hold during
reproducer replay, because we pass the result of GetPath to the VFS.
This is an empty string, which the VFS converts to an absolute directory
by prepending the current working directory, before looking it up in the
YAML mapping. This means that an empty FileSpec will exist when the
current working directory does. This breaks at least one test
(TestAddDsymCommand.py) when ran from replay.
This patch special cases empty FileSpecs and returns a sensible result
before calling GetPath and forwarding the call.
Differential revision: https://reviews.llvm.org/D77351
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
rdar://60512489
Differential Revision: https://reviews.llvm.org/D77108
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.
Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.
It uses clang::Lexer which will tokenize operator<<A::B> into:
tok::kw_operator
tok::lessless
tok::raw_identifier
Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.
Differential Revision: https://reviews.llvm.org/D76168
Summary:
When using IPv6 host:port pairs, typically the host is put inside
brackets, such as [2601🔢...:0213]:5555, and the UriParser
can handle this format.
However, the Android infrastructure in LLDB assumes an additional
brackets around the host:port pair, such that the entire host:port
string can be treated as the host (which is used as an Android Serial
Number), and UriParser cannot handle multiple brackets. Parsing
inputs with such extra backets requires searching the closing bracket
from the right.
Test: BracketedHostnameWithPortIPv6 covers the case mentioned above
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: kwk, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76736
This patch changes the way the StackFrame Recognizers match a certain
frame.
Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).
Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.
rdar://60386577
Differential Revision: https://reviews.llvm.org/D76188
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The current implementation isn't very resilient when it comes to the
output of xcrun. Currently it cannot deal with:
- Trailing newlines.
- Leading newlines and errors/warnings before the Xcode path.
- Xcode not being named Xcode.app.
This extract the logic into a helper in PlatformDarwin and fixes those
issues. It's also the first step towards removing code duplication
between the different platforms and downstream Swift.
Differential revision: https://reviews.llvm.org/D76261
Add YAML traits for ArchSpec and ProcessInstanceInfo so they can be
serialized for the reproducers.
Differential revision: https://reviews.llvm.org/D76004
Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.
Differential revision: https://reviews.llvm.org/D76002
offset_t is unsigned, so if the RHS is signed we get a warning from clang:
warning: comparison of integers of different signs: 'const unsigned long long' and 'const int'
If a producer emits a nonzero segment size, `lldb` will silently read
incorrect values and crash, or do something worse later as the tuple
size is expected to be 2, rather than 3.
Neither LLVM, nor GCC produce segmented aranges, but this dangerous case
should still be checked and handled.
Reviewed by: clayborg, labath
Differential Revision: https://reviews.llvm.org/D75925
Subscribers: lldb-commits
Tags: #lldb
Summary: This adds unit tests for FindEntryIndexesThatContain, this is done in preparation for changing the logic of the function.
Reviewers: labath, teemperor
Reviewed By: labath
Subscribers: arphaman, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75180
Summary:
This packet is necessary to make lldb work with the remote-gdb stub in
user mode qemu when running position-independent binaries. It reports
the relative position (load bias) of the loaded executable wrt. the
addresses in the file itself.
Lldb needs to know this information in order to correctly set the load
address of the executable. Normally, lldb would be able to find this out
on its own by following the breadcrumbs in the process auxiliary vector,
but we can't do this here because qemu does not support the
qXfer:auxv:read packet.
This patch does not implement full scope of the qOffsets packet (it only
supports packets with identical code, data and bss offsets), because it
is not fully clear how should the different offsets be handled and I am
not aware of a producer which would make use of this feature (qemu will
always
<https://github.com/qemu/qemu/blob/master/linux-user/elfload.c#L2436>
return the same value for code and data offsets). In fact, even gdb
ignores the offset for the bss sections, and uses the "data" offset
instead. So, until the we need more of this packet, I think it's best
to stick to the simplest solution possible. This patch simply rejects
replies with non-uniform offsets.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74598
AVR usually uses two byte addresses. By making DataExtractor deal with
this, it is possible to load AVR binaries that don't have debug info
associated with them.
Differential Revision: https://reviews.llvm.org/D73969
Since f9568a9549 this function takes a
CompilerDeclContext reference instead of a pointer. It overlooked this function
when I fixed the compilation for FindTypes.
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
The previously landed patch got reverted because it was lacking:
(1) A plugin definition for the Objective-C language runtime,
(2) The dependency between the Static and WASM dynamic loader,
(3) Explicit initialization of ScriptInterpreterNone for lldb-test.
All issues have been addressed in this patch.
Differential revision: https://reviews.llvm.org/D73067
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Differential revision: https://reviews.llvm.org/D73067
Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.
This patch does:
- add support for the .debug_cu_index section to our DWARFContext
- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors.
This argument is used to look up the offsets of the debug_info and
debug_abbrev contributions in the sections of the dwp file.
- makes sure the creation of the DebugInfo object as well as the initial
discovery of DWARFUnits is thread-safe, as we can now call this
concurrently when doing parallel indexing.
This patch does not:
- use the DWARFUnitIndex to search for other kinds of contributions
(debug_loc, debug_ranges, etc.). This means that units which reference
these sections will not work correctly. These will be handled by
follow-up patches, but even the present level of support is sufficient
to enable basic functionality.
- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this
problem by ensuring everything is initialized ahead of time. However,
this is something we will run into more often as we try to use more of
llvm, and so I plan to start looking into our options here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: mgorny, mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73783
Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" register numbers.
Besides being verbose, this information was also incomplete (new registers like
xmm16-31 were missing) and sometimes even downright wrong (ymm register
numbers).
Most of this information is available via llvm's MCRegisterInfo. This patch
creates a new class, MCBasedABI, which retrieves the eh and debug frame register
numbers this way. The tricky part here is that the llvm class uses all-caps
register names, whereas lldb register are lowercase, and sometimes called
slightly differently. Therefore this class introduces some hooks to allow a
subclass to customize the MC lookup. The subclass also needs to suply the
"generic" register numbers, as this is an lldb invention.
This patch ports the x86_64 ABI classes to use the new register info mechanism.
It also creates a new "ABIx86_64" class which can be used to house code common
to x86_64 both ABIs. Right now, this just consists of a single function, but
there are plenty of other things that could be moved here too.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74244
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.
This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.
Reviewers: teemperor, JDevlieghere, jingham
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74153
This reimplements commit 6b2979c123 and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.
DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.
Differential Revision: https://reviews.llvm.org/D74252
One way to register a recognizer is to use RegularExpressionSP for the
module and symbol.
In order to match a symbol regardless of the module, the recognizer can
be registered with a nullptr for the module. However, this cause the
frame recognizer list command to crash because it calls
RegularExpression::GetText without checking if the shared pointer is valid.
This patch adds checks for the symbol and module RegularExpressionSP.
Differential Revision: https://reviews.llvm.org/D74212
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
lldb-forward.h is convenient in many ways, but having clang-based
class forward declarations in there makes it easy to proliferate uses of clang
outside of plugins. Removing them makes you much more conscious of when
you're using something from clang and marks where we're using things
from clang in non-plugins.
Differential Revision: https://reviews.llvm.org/D73935
DataExtractor::GetMaxS64Bitfield performs a shift with UB in order to
construct a bitmask when bitfield_bit_size is 64. The current
implementation actually does “work” in this case, because the assumption
that the shift result is 0 holds, and 0 minus 1 gives the all-ones value
(the correct mask). However, the more readable/maintainable approach
might be to use an off-the-shelf UB-free helper.
Fixes a UBSan issue:
"col" : 37,
"description" : "invalid-shift-exponent",
"filename" : "/Users/vsk/src/llvm-project-master/lldb/source/Utility/DataExtractor.cpp",
"instrumentation_class" : "UndefinedBehaviorSanitizer",
"line" : 615,
"memory_address" : 0,
"summary" : "Shift exponent 64 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long')",
rdar://59117758
Differential Revision: https://reviews.llvm.org/D73913
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
Use the std::string conversion operator introduced in
d7049213d0. The SmallString in the log
statement doesn't require conversion at all when using the variadic log
macro.
Summary:
I noticed this strange line in `ASTImporterDelegate::ImportDefinitionTo` which doesn't make a lot of sense:
```
to_tag->setCompleteDefinition(from_tag->isCompleteDefinition());
```
It forcibly sets the imported TagDecl to be defined if the source TagDecl was defined. This doesn't make any
sense as in this code we already forced the ASTImporter to import the definition so this should always be
a no-op.
Turns out this is hiding two bugs:
1. The way we handle forward declarations in the debug info that might be completed later is that we
import them and then mark them as having external lexical storage. This makes Clang ask for the definition
later when it needs it (at which point we hopefully have the definition around and can complete it). However,
this is currently not completing the forward decls with external storage but instead creates a duplicated decl
in the target AST which is then defined. The forward decl is kept incomplete after the import and we just
forcibly make it a definition of the record without any content with our workaround. The TestSharedLib* tests
is only passing because of this.
2. Minimal import of lambdas is broken and never imports the definition it seems. That appears to be a bug
in the ASTImporter which gives the definition of lambda's some special treatment. TestLambdas.py is actually
broken but is passing because of this workaround.
This patch fixes the first bug by forcing the ASTImporter to import to the target forward declaration. We can't
delete the workaround as the second bug is still around but that will be a follow up review for the ASTImporter.
However it will get rid of all the duplicated RecordDecls that are in our expression AST that are strangely defined
but don't have any of the fields they are supposed to have.
Reviewers: shafik, labath
Reviewed By: shafik
Subscribers: aprantl, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73345
This has the same behavior as converting std::string_view to
std::string. This is an expensive conversion, so explicit conversions
are helpful for avoiding unneccessary string copies.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
The GetRawLine currently returns the full command line used
to create the CompletionRequest. So for example for "foo b[tab] --arg"
it would return the whole string instead of "foo b". Usually
completion code makes the wrong assumption that the cursor is at
the end of the line and handing out the complete line will cause
that people implement completions that also make this assumption.
This patch makes GetRawLine() return only the string until the
cursor and hides the suffix (so that the cursor is always at the
end of this string) and adds another function GetRawLineWithUnusedSuffix
that is specifically the line with the suffix that isn't used by
the CompletionRequest for argument parsing etc.
There is only one user of this new function that actually needs the
suffix and that is the expression command which needs the suffix to
detect if it is in the raw or argument part of the command (by looking
at the "--" separator).
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
Summary:
I often struggle to understand what exactly LLDB is doing by looking at our expression evaluation logging as our messages look like this:
```
CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing (TagDecl*)0x7ff31f01d568 named DeclName1
```
From the log messages it's unclear what this ASTContext is. Is it the scratch context, the expression context, some decl vendor context or a context from a module?
The pointer value isn't helpful for anyone unless I'm in a debugger where I could inspect the memory at the address. But even with a debugger it's not easy to
figure out what this ASTContext is without having deeper understanding about all the different ASTContext instances in LLDB (e.g., valid SourceLocation
from the file system usually means that this is the Objective-C decl vendor, a file name from multiple expressions is probably the scratch context, etc.).
This patch adds a name field to ClangASTContext instances that we can use to store a name which can be used for logging and debugging. With this
our log messages now look like this:
```
CompleteTagDecl[2] on scratch ASTContext. Completing (TagDecl*)0x7ff31f01d568 named Foo
```
We can now also just print a ClangASTContext from the debugger and see a useful name in the `m_display_name` field, e.g.
```
m_display_name = "AST for /Users/user/test/main.o";
```
Reviewers: shafik, labath, JDevlieghere, mib
Reviewed By: shafik
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72391
Summary:
CXXRecordDecls that have a move constructor but no copy constructor need to
have their implicit copy constructor marked as deleted (see C++11 [class.copy]p7, p18)
Currently we don't do that when building an AST with ClangASTContext which causes
Sema to realise that the AST is malformed and asserting when trying to create an implicit
copy constructor for us in the expression:
```
Assertion failed: ((data().DefaultedCopyConstructorIsDeleted || needsOverloadResolutionForCopyConstructor())
&& "Copy constructor should not be deleted"), function setImplicitCopyConstructorIsDeleted, file include/clang/AST/DeclCXX.h, line 828.
```
In the test case there is a class `NoCopyCstr` that should have its copy constructor marked as
deleted (as it has a move constructor). When we end up trying to tab complete in the
`IndirectlyDeletedCopyCstr` constructor, Sema realises that the `IndirectlyDeletedCopyCstr`
has no implicit copy constructor and tries to create one for us. It then realises that
`NoCopyCstr` also has no copy constructor it could find via lookup. However because we
haven't marked the FieldDecl as having a deleted copy constructor the
`needsOverloadResolutionForCopyConstructor()` returns false and the assert fails.
`needsOverloadResolutionForCopyConstructor()` would return true if during the time we
added the `NoCopyCstr` FieldDecl to `IndirectlyDeletedCopyCstr` we would have actually marked
it as having a deleted copy constructor (which would then mark the copy constructor of
`IndirectlyDeletedCopyCstr ` as needing overload resolution and Sema is happy).
This patch sets the correct mark when we complete our CXXRecordDecls (which is the time when
we know whether a copy constructor has been declared). In theory we don't have to do this if
we had a Sema around when building our debug info AST but at the moment we don't have this
so this has to do the job for now.
Reviewers: shafik
Reviewed By: shafik
Subscribers: aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72694
and document the shortcomings of LLDB's partially defined DW_OP_piece
handling.
This would manifest as "DW_OP_piece for offset foo but top of stack is
of size bar".
rdar://problem/46262998
Differential Revision: https://reviews.llvm.org/D72880
By switching to Scalars that are backed by explicitly-sized APInts we
can avoid a bug that increases the buffer reserved for a small piece
to the next-largest host integer type.
This manifests as "DW_OP_piece for offset foo but top of stack is of size bar".
Differential Revision: https://reviews.llvm.org/D72879
Summary:
In Debug builds we call VerifyDecl in ClangASTContext::CreateFunctionDeclaration which in turn
calls `getAccess` on the created FunctionDecl. As we passed in a RecordDecl as the DeclContext
for the FunctionDecl, we end up hitting the assert in `getAccess` that checks that we never have
a Decl inside a Record without a valid AccessSpecifier. FunctionDecls are never in RecordDecls
(that would be a CXXMethodDecl) so setting a access specifier would not be the correct way to
fix this.
Instead this patch does the same thing that DWARFASTParserClang::ParseSubroutine is doing:
We pass in the FunctionDecl with the TranslationUnit as the DeclContext. That's not ideal but
it is how we currently do it when creating our debug info AST, so the unit test should do
the same.
Reviewers: shafik
Reviewed By: shafik
Subscribers: aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72359
As suggested by @labath extended RangeDataVector so that user can provide
custom sorting of the Entry's `data' field for D63540.
https://reviews.llvm.org/D63540
RangeData functions were used just by RangeDataVector (=after I removed them
LLDB still builds fine) which no longer uses them so I removed them.
Differential revision: https://reviews.llvm.org/D72460
Creating an ASTContext with an unknown triple is rarely a good idea (as usually
all our ASTs have a valid triple that is either from the host or the target) and the
default argument makes it far to easy to implicitly create such an AST. Let's
remove it and force people to pass a triple.
The only place where we don't pass a triple is a DWARFASTParserClangTests
where we now just pass the host triple instead (the test doesn't depend on any
triple so this shouldn't change anything).
This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.
Summary:
We currently don't set access specifiers for function template declarations. This seems to be fine
as long as the function template is not declared inside any record in which case Clang asserts
with the following once we try to query it's access:
```
Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function AccessDeclContextSanity,
```
This patch just marks these function template declarations as public to make Clang happy.
Reviewers: shafik, teemperor
Reviewed By: teemperor
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71909
This adds a check that the ClangASTContext actually fits to the
DeclContext that we want to create a CompilerDeclContext for. If
the ClangASTContext (and its associated ASTContext) does not fit
to the DeclContext (that is, the DeclContext wasn't created by the
ASTContext), all computations using this malformed CompilerDeclContext
will yield unpredictable results.
Also fixes the only place that actually hits this assert which is the
construction of a CompilerDeclContext in ClangExpressionDeclMap
where we pass an unrelated ASTContext instead of the ASTContext
of the current expression.
I had to revert my previous change to DWARFASTParserClangTests.cpp
back to using the unsafe direct construction of CompilerDeclContext
as this assert won't work if the DeclContext we pass isn't a valid
DeclContext in the first place.
Summary:
Many of our tests need to initialize certain subsystems/plugins of LLDB such as
`FileSystem` or `HostInfo` by calling their static `Initialize` functions before the
test starts and then calling `::Terminate` after the test is done (in reverse order).
This adds a lot of error-prone boilerplate code to our testing code.
This patch adds a RAII called SubsystemRAII that ensures that we always call
::Initialize and then call ::Terminate after the test is done (and that the Terminate
calls are always in the reverse order of the ::Initialize calls). It also gets rid of
all of the boilerplate that we had for these calls.
Per-fixture initialization is still not very nice with this approach as it would
require some kind of static unique_ptr that gets manually assigned/reseted
from the gtest SetUpTestCase/TearDownTestCase functions. Because of that
I changed all per-fixture setup to now do per-test setup which can be done
by just having the SubsystemRAII as a member of the test fixture. This change doesn't
influence our normal test runtime as LIT anyway runs each test case separately
(and the Initialize/Terminate calls are anyway not very expensive). It will however
make running all tests in a single executable slightly slower.
Reviewers: labath, JDevlieghere, martong, espindola, shafik
Reviewed By: labath
Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71630
The CompilerDeclContext constructor takes a void* pointer which
means that all callers of this constructor need to first explicitly
convert all pointers to clang::DeclContext*. This causes that we
for example can't just pass a TranslationUnitDecl* to the constructor without
first casting it to its parent class (as it inherits from both
Decl and DeclContext so the void* pointer is actually a Decl*).
This patch introduces a utility function in the ClangASTContext
which gets rid of the requirement to cast all pointers to
clang::DeclContext. Also moves all constructor calls to use this
function instead which is NFC (beside the change in
DWARFASTParserClangTests.cpp).
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a
while that the ASTContext is not a nullptr. This causes that we still have a lot of code
that is doing nullptr checks on the result of getASTContext() which is all unreachable code.
This patch changes the return value to a reference to make it clear this can't be a nullptr
and deletes all the nullptr checks.
Their naming is misleading as they only return the
ClangASTContext-owned variables. For ClangASTContext instances constructed
for a given clang::ASTContext they silently generated duplicated instances
(e.g., a second IdentifierTable) that were essentially unusable.
This removes all these getters as they are anyway not very useful in comparison
to just calling the clang::ASTContext getters. The initialization
code has been moved to the CreateASTContext initialization method so that all
code for making our own clang::ASTContext is in one place.
This implements a very elementary Lua script interpreter. It supports
running a single command as well as running interactively. It uses
editline if available. It's still missing a bunch of stuff though. Some
things that I intentionally ingored for now are that I/O isn't properly
hooked up (so every print goes to stdout) and the non-editline support
which is not handling a bunch of corner cases. The latter is a matter of
reusing existing code in the Python interpreter.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71234
We already pass a Decl here and the additional ASTContext needs to
match the Decl. We might as well just pass the Decl and then extract
the ASTContext from that.
This adds a unit test for looking up persistent declarations in the scratch AST
context. Also adds the `GetPersistentDecl` hook to the ClangExpressionDeclMap
that this unit test can emulate looking up persistent variables without having
a lldb_private::Target.
The ClangExpressionDeclMap should be testable from a unit test. This is currently
impossible as they have both dependencies on Target/ExecutionContext from their
constructor. This patch allows constructing these classes without an active Target
and adds the missing tests for running without a target that we can do at least
a basic lookup test without crashing.
Summary:
These types were handled in some places, but not others. This resulted
in (for example) not being able to display members of structs whose
types were defined using these constructs.
Using getLocallyUnqualifiedSingleStepDesugaredType for these types is
not fully equivalent, as it will only desugar them if the types are not
instantiation-dependent, whereas previously we did that unconditionally.
It's not clear to me which behavior is correct here, but the test suite
does not seem to care either way.
Reviewers: teemperor, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71405
As suggested by Pavel in a code review:
> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..
Differential revision: https://reviews.llvm.org/D71280
GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit. So this replacing it with a explicit cast and refactors the code around it to use an early exit.
Differential Revision: https://reviews.llvm.org/D70992
Summary:
Yet another step on the long road towards getting rid of lldb's Stream class.
We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push
in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs.
I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71052
Summary:
This patch adds code which will substitute references to the full object
constructors/destructors with their base object versions.
Like all substitutions in this category, this operation is not really
sound, but doing this in a more precise way allows us to get rid of a
much larger hack -- matching function according to their demangled
names, which effectively does the same thing, but also much more.
This is a (very late) follow-up to D54074.
Background: clang has an optimization which can eliminate full object
structors completely, if they are found to be equivalent to their base
object versions. It does this because it assumes they can be regenerated
on demand in the compile unit that needs them (e.g., because they are
declared inline). However, this doesn't work for the debugging scenario,
where we don't have the structor bodies available -- we pretend all
constructors are defined out-of-line as far as clang is concerned. This
causes clang to emit references to the (nonexisting) full object
structors during expression evaluation.
Fun fact: This is not a problem on darwin, because the relevant
optimization is disabled to work around a linker bug.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70721
Summary:
This patch fixes a bug where when target triple created from elf information
is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging
both triple results in armv8l--unknown-unknown.
This happens because we order a triple update while calling CoreUpdated and
CoreUpdated creates a new triple with no vendor or environment information.
Making sure we do not update triple and just update to more specific core
fixes the issue.
Reviewers: labath, jasonmolenda, clayborg
Reviewed By: jasonmolenda
Subscribers: jankratochvil, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70155
Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name of an existing module (for example).
These comparisons used FileSpec::Equal, which had some support for it
(via the full=false argument), but it was not a good fit for this job.
For one, it did a symmetric comparison, which makes sense for a function
called "equal", but not for typical searches (when searching for
"/foo/bar.so", we don't want to find a module whose name is just
"bar.so"). This resulted in patterns like:
if (FileSpec::Equal(pattern, file, pattern.GetDirectory()))
which would request a "full" match only if the pattern really contained
a directory. This worked, but the intended behavior was very unobvious.
On top of that, a lot of the code wanted to handle the case of an
"empty" pattern, and treat it as matching everything. This resulted in
conditions like:
if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory())
which are nearly impossible to decipher.
This patch introduces a FileSpec::Match function, which does exactly
what most of FileSpec::Equal callers want, an asymmetric match between a
"pattern" FileSpec and a an actual FileSpec. Empty paterns match
everything, filename-only patterns match only the filename component.
I've tried to update all callers of FileSpec::Equal to use a simpler
interface. Those that hardcoded full=true have been changed to use
operator==. Those passing full=pattern.GetDirectory() have been changed
to use FileSpec::Match.
There was also a handful of places which hardcoded full=false. I've
changed these to use FileSpec::Match too. This is a slight change in
semantics, but it does not look like that was ever intended, and it was
more likely a result of a misunderstanding of the "proper" way to use
FileSpec::Equal.
[In an ideal world a "FileSpec" and a "FileSpec pattern" would be two
different types, but given how widespread FileSpec is, it is unlikely
we'll get there in one go. This at least provides a good starting point
by centralizing all matching behavior.]
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70851
Summary:
A most of these tests create FileSpecs with a hardcoded style. Add
utility functions which create a file spec of a given style to simplify
things.
While in there add SCOPED_TRACE messages to tests which loop over
multiple inputs to ensure it's clear which of the inputs failed.
Reviewers: teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70814
Summary:
I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.
Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.
Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70241
Summary:
Clang's raw Lexer doesn't produce any tokens for trailing backslashes in a line. This doesn't work with
LLDB's Clang highlighter which builds the source code to display from the list of tokens the Lexer returns.
This causes that lines with trailing backslashes are lacking the backslash and the following newline when
rendering source code in LLDB.
This patch removes the trailing newline from the current line we are highlighting. This way Clang doesn't
drop the backslash token and we just restore the newline after tokenising.
Fixes rdar://57091487
Reviewers: JDevlieghere, labath
Reviewed By: JDevlieghere, labath
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70177
Summary:
This patch updates the last user of ArgInfo::count and deletes
it. I also delete `GetNumInitArguments()` and `GetInitArgInfo()`.
Classess are callables and `GetArgInfo()` should work on them.
On python 3 it already works, of course. `inspect` is good.
On python 2 we have to add yet another special case. But hey if
python 2 wasn't crufty we wouln't need python 3.
I also delete `is_bound_method` becuase it is unused.
This path is tested in `TestStepScripted.py`
Reviewers: labath, mgorny, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69742
This is a quick followup to this commit:
https://reviews.llvm.org/rGa69bbe02a2352271e8b14542073f177e24c499c1
In that, I #pragma-squelch this warning in `ScriptInterpreterPython.cpp`
but we get the same warning in `PythonTestSuite.cpp`.
This patch squelches the same warning in the same way as the
reviweed commit. I'm submitting it without review under the
"obviously correct" rule.
At least if this is incorrect the main commit was also incorrect.
By the way, as far as I can tell, these functions are extern "C" because
SWIG does that to everything, not because they particularly need to be.
Summary:
Move breakpoints from the old, bad ArgInfo::count to the new, better
ArgInfo::max_positional_args. Soon ArgInfo::count will be no more.
It looks like this functionality is already well tested by
`TestBreakpointCommandsFromPython.py`, so there's no need to write
additional tests for it.
Reviewers: labath, jingham, JDevlieghere
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69468
The goal of this refactor is to enable ProcessMinidump to take into
account the loaded modules and their sections when computing the
permissions of various ranges of memory, as discussed in D66638.
This patch moves some of the responsibility for computing the ranges
from MinidumpParser into ProcessMinidump. MinidumpParser still does the
parsing, but ProcessMinidump becomes responsible for answering the
actual queries about memory ranges. This will enable it (in a follow-up
patch) to augment the information obtained from the parser with data
obtained from actual object files.
The changes in the actual code are fairly straight-forward and just
involve moving code around. MinidumpParser::GetMemoryRegions is renamed
to BuildMemoryRegions to emphasize that it does no caching. The only new
thing is the additional bool flag returned from this function. This
indicates whether the returned regions describe all memory mapped into
the target process. Data obtained from /proc/maps and the MemoryInfoList
stream is considered to be exhaustive. Data obtained from Memory(64)List
is not. This will be used to determine whether we need to augment the
data or not.
This reshuffle means that it is no longer possible/easy to test some of
this code via unit tests, as constructing a ProcessMinidump instance is
hard. Instead, I update the unit tests to only test the parsing of the
actual data, and test the answering of queries through a lit test using
the "memory region" command. The patch also includes some tweaks to the
MemoryRegion class to make the unit tests easier to write.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69035
For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no
way to write a generic "stop when my caller is..." function, and then specify the caller when you add the
command to a breakpoint.
With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in
the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right
signature) when the breakpoint is hit. Then in lldb, you can say:
(lldb) break com add -F caller_is -k caller_name -v Foo
More generally this will allow us to write reusable Python breakpoint commands.
Differential Revision: https://reviews.llvm.org/D68671
Looks like on windows googlemock regexes treat newlines differently
from on darwin. This patch fixes the regex in this test so it
will work on both.
Fixes: https://reviews.llvm.org/D69214
llvm-svn: 375477
Summary:
With this patch, only the no-argument form of `Reset()` remains in
PythonDataObjects. It also deletes PythonExceptionState in favor of
PythonException, because the only call-site of PythonExceptionState was
also using Reset, so I cleaned up both while I was there.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69214
llvm-svn: 375475
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
Summary:
When users define a debugger command from python, they provide a callable
object. Because the signature of the function has been extended, LLDB
needs to inspect the number of parameters the callable can take.
The rule it was using to decide was weird, apparently not tested, and
giving wrong results for some kinds of python callables.
This patch replaces the weird rule with a simple one: if the callable can
take 5 arguments, it gets the 5 argument version of the signature.
Otherwise it gets the old 4 argument version.
It also adds tests with a bunch of different kinds of python callables
with both 4 and 5 arguments.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69014
llvm-svn: 375333
Summary: The types defined for it in LLDB are now redundant with core types.
Reviewers: labath, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68658
llvm-svn: 375243
Summary:
I'd like to eliminate all forms of Reset() and all public constructors
on these objects, so the only way to make them is with Take<> and Retain<>
and the only way to copy or move them is with actual c++ copy, move, or
assignment.
This is a simple place to start.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69080
llvm-svn: 375182
Summary:
The current implementation of PythonCallable::GetNumArguments
is not exception safe, has weird semantics, and is just plain
incorrect for some kinds of functions.
Python 3.3 introduces inspect.signature, which lets us easily
query for function signatures in a sane and documented way.
This patch leaves the old implementation in place for < 3.3,
but uses inspect.signature for modern pythons. It also leaves
the old weird semantics in place, but with FIXMEs grousing about
it. We should update the callers and fix the semantics in a
subsequent patch. It also adds some tests.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68995
llvm-svn: 375181
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
Summary:
The previous attempt at making nameless process not match when searching for a
given name failed because the macos implementation was depending on this detail
in its partial matching strategy. Doing partial matching to avoid expensive
lookups is a perfectly valid thing to do, the way it was implemented seems
somewhat unexpected.
This patch implements it differently by providing special
methods in the ProcessInstanceInfoMatch which match only a subset of fields,
and changes mac host code to use those instead.
Then, it re-applies r373925 to get make the ProcessInstanceInfoMatch with a
name *not* match a nameless process.
Reviewers: JDevlieghere, teemperor, jingham
Subscribers: wallace, lldb-commits
Differential Revision: https://reviews.llvm.org/D68631
llvm-svn: 374529
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
Unwind plan augmentation should compute the plan row at offset x from
the instruction before offset x, but currently we compute it from the
instruction at offset x. Note that this behavior is a regression
introduced when moving the x86 assembly inspection engine to its own
file
(1c9858b298 (diff-375a2be066db6f34bb9a71442c9b71fcL913));
the original version handled this properly by copying the previous
instruction out before advancing the instruction pointer.
The relevant bug with more info is here: https://bugs.llvm.org/show_bug.cgi?id=43561
Differential Revision: https://reviews.llvm.org/D68454
Patch by Jaroslav Sevcik <jarin@google.com>.
llvm-svn: 374342
EXPECT_EQ contains an if-else statement. It also contains some magic to
suppress the dangling else warnings, but it seems that some new
compilers can see through that...
llvm-svn: 374341
Summary:
The `if (*cstr_end == '\0')` in the previous code checked if the previous loop terminated because it
found a null terminator or because it reached the end of the data. However, in the case that we hit
the end of the data before finding a null terminator, `cstr_end` points behind the last byte in our
data and `*cstr_end` reads the memory behind the array (which may be uninitialised)
This patch just rewrites that function use `std::find` and adds the relevant unit tests.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68773
llvm-svn: 374311
Stack unwinding was sometimes failing when trying to unwind stacks in 32 bit ARM. I discovered this was because the EH frame register numbers were not set. This patch fixes this issue and adds a unit test to verify this doesn't regress.
Differential Revision: https://reviews.llvm.org/D68088
llvm-svn: 374246
Testing whether a name is mangled or not is extremely cheap and can be
done by looking at the first two characters. Mangled knows how to do
it. On the flip side, many call sites that currently pass in an
is_mangled determination do not know how to correctly do it (for
example, they leave out Swift mangling prefixes).
This patch removes this entry point and just forced Mangled to
determine the mangledness of a string itself.
Differential Revision: https://reviews.llvm.org/D68674
llvm-svn: 374180
Summary:
This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added.
I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.
I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.
I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long 0xf0004668 ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov r0, sp
app_process32[0x1642]: andeq r0, r0, r0
```
Reviewers: clayborg, labath, wallace, espindola
Reviewed By: labath
Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68533
llvm-svn: 374132
I often use `ninja lldb-test-deps` to build all the test dependencies
before running a subset of the tests with `lit --filter`. This
functionality seems to break relatively often because test dependencies
are tracked in an ad-hoc way acrooss cmake files. This patch adds a
helper function `add_lldb_test_dependency` to unify test dependency
tracking by adding dependencies to lldb-test-deps.
Differential revision: https://reviews.llvm.org/D68612
llvm-svn: 373996
Since D68289, a couple of tests on linux started being extremely flaky.
All of them were doing name-based attaching and were failing because
they couldn't find an unambiguous process to attach to.
The patch above changed the process finding logic, so that failure to
find a process name does not constitute an error. This meant that a lot
more transient processes showed up in the process list during the test
suite run. Previously, these processes would not appear as they would be
gone by the time we went to read their executable name, arguments, etc.
Now, this alone should not cause an issue were it not for the fact that
we were considering a process with no name as if it matched by default
(even if we were explicitly searching for a process with a specified
name). This meant that any of the "transient" processes with no name
would make the name match ambiguous. That clearly seems like a bug to me
so I fix that.
llvm-svn: 373925
Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate.
This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be.
llvm-svn: 373687
Summary:
I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.
I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.
I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long 0xf0004668 ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov r0, sp
app_process32[0x1642]: andeq r0, r0, r0
```
Reviewers: clayborg, labath, wallace, espindola
Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68069
llvm-svn: 373680
This will allow us to write reusable scripted ThreadPlans, since
you can use key/value pairs with known keys in the plan to parametrize
its behavior.
Differential Revision: https://reviews.llvm.org/D68366
llvm-svn: 373675
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
llvm-svn: 373564
This patch is the final step in my quest to get rid of the JSON parser
in LLDB. Vedant's coverage report [1] shows that it was mostly untested.
Furthermore, the LLVM implementation has a much nicer API and using it
means one less thing to maintain for LLDB.
[1] http://lab.llvm.org:8080/coverage/coverage-reports/index.html
Differential revision: https://reviews.llvm.org/D68305
llvm-svn: 373501
Reason for this patch is the Ssame reason as for the previous patches:
Having a ClangASTContext and being able to switch the associated ASTContext isn't
a use case we have (or should have), so let's simplify all this code.
This way it becomes clearer in what order we initialize data structures.
The DWARFASTParserClangTests changes are necessary as the test is using
a ClangASTContext but relied on the fact that no called function ever calls
getASTContext() on our ClangASTContext (as that would create the ASTContext).
As we now always create the ASTContext the fact that we had an uninitialized
FileSystem made the test crash.
llvm-svn: 373457
The original test was passing false to the append argument of
FindTypes (the only use of this feature!). This patch now replicates
that by passing a fresh TypeMap into the function where applicable.
llvm-svn: 373409
This patch replaces the hand-rolled JSON emission in StructuredData with
LLVM's JSON library.
Differential revision: https://reviews.llvm.org/D68248
llvm-svn: 373359
In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.
This patch simply removes the size_t return parameter altogether —
it's not that useful.
rdar://problem/55500457
Differential Revision: https://reviews.llvm.org/D68169
llvm-svn: 373344
Summary:
It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo
structs (which is what is needed to turn dwarf register numbers into
strings).
Reviewers: JDevlieghere, aprantl, jasonmolenda
Subscribers: tatyana-krasnukha, lldb-commits
Differential Revision: https://reviews.llvm.org/D67966
llvm-svn: 373208
The unit tests started failing on Windows after my recent patch that
ensured we always deal with absolute paths. This should fix that.
llvm-svn: 373114
Summary:
This patch converts FileSystem::Open from this prototype:
Status
Open(File &File, const FileSpec &file_spec, ...);
to this one:
llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);
This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67996
llvm-svn: 373003
This is the only legitimate use we currently have for modifying
a CompletionRequest. Add a utility function for this purpose
and remove the remaining setters which go against the idea of
having an immutable CompletionRequest.
llvm-svn: 372858
Adrian added a sanity check to the socket tests to ensure the $TMPDIR is
not too long for a socket. While this is great for diagnosing the
problem it doesn't really solve the problem for environment where you
have no control over that variable such as in CI. I propose to just skip
the test in that case similar to what we do for tests that rely on
targets that are not currently build, etc.
Differential revision: https://reviews.llvm.org/D67972
llvm-svn: 372774
This implements
DWARFASTParserClang::EnsureAllDIEsInDeclContextHaveBeenParsed so as to
provide a faster way to ensure all DIEs linked to a certain declaration
context have been parsed.
Currently, we rely on SymbolFileDWARF::ParseDeclsForContext calling
DWARFASTParserClang::GetDIEForDeclContext, and only then
DWARFASTParserClang::GetDeclForUIDFromDWARF. This change shortcuts that
logic and removes redundant calls to DWARFASTParserClang::
GetClangDeclForDIE by deleting DIEs from the m_decl_ctx_to_die map once
they have been parsed.
Differential Revision: https://reviews.llvm.org/D67760
Patch by Guilherme Andrade <guiandrade@google.com>.
llvm-svn: 372744
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:
* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).
This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).
The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.
Reviewers: aprantl, shafik, jdoerfert
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D67760
llvm-svn: 372716
We currently have two lists in the CompletionRequest that we
inherited from the old API: The complete list of arguments ignoring
where the user requested completion and the list of arguments that
stops at the cursor. Having two lists of arguments is confusing
and can lead to subtle errors, so let's remove the complete list
until we actually need it.
llvm-svn: 372692
lvm_private::File::GetStream() can fail if m_options == 0
It's not clear from the header a File created with a descriptor will be
not be usable by many parts of LLDB unless SetOptions is also called,
but it is.
This is because those parts of LLDB rely on GetStream() to use the
file, and that in turn relies on calling fdopen on the descriptor. When
calling fdopen, GetStream relies on m_options to determine the access
mode. If m_options has never been set, GetStream() will fail.
This patch adds options as a required argument to File::SetDescriptor
and the corresponding constructor.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67792
llvm-svn: 372652
If the file has m_stream, it may not have a m_descriptor.
GetWaitableHandle() should call GetDescriptor(), which will call
fileno(), so it will get waitable descriptor whenever one is available.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67789
llvm-svn: 372644
These ifdefs contain code that isn't specific to MSVC but useful for
any windows target, like MinGW.
Differential Revision: https://reviews.llvm.org/D67893
llvm-svn: 372592
The fact that index==-1 means "no arguments" is not obvious and only
used in one place from what I can tell. Also fixes several warnings
about using the cursor index as if it was a size_t when comparing.
Not fully NFC as we now also correctly update the partial argument list
when injecting the fake empty argument in the CompletionRequest
constructor.
llvm-svn: 372566
We should in general not allow external code to fiddle with the internals of
CompletionRequest, but until this is gone let's at least provide a utility
function that makes this less dangerous.
This also now correct updates the partially parsed argument list,
but it doesn't seem to be used by anything that is behind one of
the current shift/SetCursorIndex calls, so this doesn't seeem to
fix any currently used completion.
llvm-svn: 372556
Summary:
These functions are only used in tests where we should test the actual flag values instead of counting all bits for an approximate check.
Also these popcount implementation aren't very efficient and doesn't seem to be optimised to anything fast.
Reviewers: davide, JDevlieghere
Reviewed By: davide, JDevlieghere
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67540
llvm-svn: 372018
To support dumping the reproducer's GDB remote packets, we need the
(de)serialization logic to live in Utility rather than the GDB remote
plugin. This patch renames StreamGDBRemote to GDBRemote and moves the
relevant packet code there.
Its uses in the GDBRemoteCommunicationHistory and the
GDBRemoteCommunicationReplayServer are updated as well.
Differential revision: https://reviews.llvm.org/D67523
llvm-svn: 371907
The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.
llvm-svn: 371842
This patch adds basic support for DW_OP_convert[1] for integer
types. Recent versions of LLVM's optimizer may insert this opcode into
DWARF expressions. DW_OP_convert is effectively a type cast operation
that takes a reference to a base type DIE (or zero) and then casts the
value at the top of the DWARF stack to that type. Internally this
works by changing the bit size of the APInt that is used as backing
storage for LLDB's DWARF stack.
I managed to write a unit test for this by implementing a mock YAML
object file / module that takes debug info sections in yaml2obj
format.
[1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1
<rdar://problem/48167864>
Differential Revision: https://reviews.llvm.org/D67369
llvm-svn: 371532
This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.
Differential revision: https://reviews.llvm.org/D67378
llvm-svn: 371474
Currently, we return all the entries such that their decl_ctx pointer >= decl_ctx provided.
Instead, we should return only the ones that decl_ctx pointer == decl_ctx provided.
Differential Revision: https://reviews.llvm.org/D66357
Patch by Guilherme Andrade <guiandrade@google.com>.
llvm-svn: 370374
Summary:
The DWARFExpression methods have a lot of arguments. This removes two of
them by removing the ability to slice the expression via two offset+size
parameters. This is a functionality that it is not always needed, and
when it is, we already have a different handy way of slicing a data
extractor which we can use instead.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D66745
llvm-svn: 370027
Constructing a std::vector from a llvm::map_range fails on windows,
apparently because std::vector expects the input iterator to have a
const operator* (map_range iterator has a non-const one).
This avoids the cleverness and unrolls the map-loop manually (which is
also slightly shorter).
llvm-svn: 369905
Summary:
Previously we moved the code which parses a single expression out of the PDB
plugin, because that was useful for DWARF expressions in breakpad. However, FPO
programs are used in breakpad files too (when unwinding on windows), so this
completes the job, and moves the rest of the FPO parser too.
Reviewers: amccarth, aleksandr.urakov
Subscribers: aprantl, markmentovai, rnk, lldb-commits
Differential Revision: https://reviews.llvm.org/D66634
llvm-svn: 369894
Summary: The fields that aren't useful for us right now are simply ignored.
Reviewers: amccarth, markmentovai
Subscribers: rnk, lldb-commits
Differential Revision: https://reviews.llvm.org/D66633
llvm-svn: 369892
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
This patch generalizes the FindTypes with CompilerContext interface to
support looking up a type of unknown kind by name, as well as looking
up a type inside an unspecified submodule. These features are
motivated by the Swift branch, but are fully tested via unit tests and
lldb-test on llvm.org. Specifically, this patch adds an AnyModule and
an AnyType CompilerContext kind.
Differential Revision: https://reviews.llvm.org/D66507
rdar://problem/54471165
llvm-svn: 369555
The EXCLUDE_FROM_ALL variable is used by add_llvm_library, but lldb does
not use that function (it uses llvm_add_library :P). Instead, set the directory
property with the same name directly.
This should fix standalone builds against an llvm install tree.
llvm-svn: 369502
This patch removes the two variant of StringExtractor::GetStringRef that
return (non-)const references to std::string. The non-const one was
being abused to reinitialize the StringExtractor and its uses are
replaced by calls to the copy asignment operator. The const variant was
refactored to return an actual llvm::StringRef.
llvm-svn: 369493
While generating the Doxygen I noticed this lone namespace that has one
class and one function in it. This moves them into lldb_private.
llvm-svn: 369485
This patch added some gtest code to the TestingSupport library. As this
is not a unit test, but a unit test library, gtest does not get added to
the include path automatically, but we have to do that ourselves. (It
was working for me without this because the compiler picked up the
system gtest instead.)
llvm-svn: 369381
previously they used a minidump-specific function for this purpose, but
this is no longer needed now that whole of yaml2obj is available as a
library.
llvm-svn: 369379
Summary:
Recently, yaml2obj has been turned into a library. This means we can use
it from our unit tests directly, instead of shelling out to an external
process. This patch does just that.
Reviewers: JDevlieghere, aadsm, espindola, jdoerfert
Subscribers: emaste, mgorny, arichardson, MaskRay, jhenderson, abrachet, lldb-commits
Differential Revision: https://reviews.llvm.org/D65949
llvm-svn: 369374
This function is just a wrapper for GetNumberOfResults and will
be removed soon. This patch just changes all calls to GetNumberOfResults
where possible (which is currently just the unit test).
llvm-svn: 369267
Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.
This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.
Differential revision: https://reviews.llvm.org/D66174
llvm-svn: 369153
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368933
Summary: Thanks to Hui Huang and the reviewers for all the help with this patch.
Reviewers: labath, Hui, jfb, clayborg, amccarth
Reviewed By: labath
Subscribers: amccarth, compnerd, dexonsmith, mgorny, jfb, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63165
llvm-svn: 368759
Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.
Differential Revision: https://reviews.llvm.org/D66102
llvm-svn: 368741
Currently ExecutionContext::GetByteOrder() always returns the host byte
order. This seems like a simple mistake: the return keyword appears to
have been omitted by accident. This patch fixes that and adds a unit
test.
Bugreport: https://llvm.org/PR37950
Differential revision: https://reviews.llvm.org/D48704
llvm-svn: 368181
After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to the symbol file directly -- in most cases that just
means calling GetSymbolFile()->foo() instead of
GetSymbolVendor()->foo().
llvm-svn: 368001
Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.
llvm-svn: 367385
When investigating a completion bug I got confused by the API.
LongestCommonPrefix finds the longest common prefix of the strings in
the string list. Instead of returning that string through an output
argument, just return it by value.
llvm-svn: 367384
SymbolFilePDB tests were using GetTypeSystemForLanguage but weren't
changed to accomodate the use of an llvm::Expected. I adjusted them
accordingly.
llvm-svn: 367368
Summary:
Instead of having SymbolVendor coordinate Symtab construction between
Symbol and Object files, make the SymbolVendor function a passthrough,
and put all of the logic into the SymbolFile.
Reviewers: clayborg, JDevlieghere, jingham, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65208
llvm-svn: 367086
The file collector class is useful for creating reproducers,
not just for LLDB, but for other tools as well in LLVM/Clang.
Differential Revision: https://reviews.llvm.org/D65237
llvm-svn: 366956
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here.
Reviewers: xiaobai, JDevlieghere, davide
Reviewed By: xiaobai, JDevlieghere
Subscribers: mgorny, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64994
llvm-svn: 366631
Summary:
We can always build debugserver, but we can't always sign it to be useable for testing. `LLDB_USE_SYSTEM_DEBUGSERVER` should only tell whether or not the system debugserver should be used for testing.
The old behavior complicated the logic around debugserver a lot. The new logic sorts out most of it.
Please note that this patch is in early stage and needs some more testing. It should not affect platfroms other than Darwin. It builds on Davide's approach to validate the code-signing identity at configuration time.
What do you think?
Reviewers: xiaobai, JDevlieghere, davide, compnerd, friss, labath, mgorny, jasonmolenda
Reviewed By: JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64806
llvm-svn: 366433
Pavel Labath