| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This disables two tests on Windows that I re-enabled in r369995.
llvm-svn: 370003
|
|
|
|
|
|
|
|
|
|
|
|
| |
The disconnect method sets the shutdown flag to true. This currently
only prevents any reads from happening, but not writes, which is
incorrect. Presumably this was just an oversight when adding
synchronization to the class. This adds the same shutdown check to the
Write method.
Over-the-shoulder reviewed by Jim!
llvm-svn: 370002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today I discovered the skipLongRunningTest decorator and to my surprise
all the tests were passing without the decorator. They don't seem to be
that expensive either, they take a few seconds but we have tests that
take much longer than that. As such I propose to remove the decorator
and enable them by default.
Differential revision: https://reviews.llvm.org/D66774
llvm-svn: 369995
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a magic return error code from debugserver to
indicate that an attach failed because of SIP being enabled in
RNBRemote::HandlePacket_v, use the extended error reporting that
Pavel added to lldb/lldb-server in https://reviews.llvm.org/D45573
<rdar://problem/39398385>
llvm-svn: 369990
|
|
|
|
|
|
|
| |
This is so that the test harness pretty-prints build error messages in
trace mode, instead of dumping a raw python bytes object.
llvm-svn: 369987
|
|
|
|
|
|
|
|
| |
The current implementation returns a bool for indicating success and
whether or not the APInt passed by reference was populated. Instead of
doing that, I think it makes more sense to return an Optional<APInt>.
llvm-svn: 369970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target
Summary:
We always have a dummy target, so any error handling regarding a missing dummy target is dead code now.
Also makes the CommandObject methods that return Target& to express this fact in the API.
This patch just for the CommandObject part of LLDB. I'll migrate the rest of LLDB in a follow-up patch that's WIP.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66737
llvm-svn: 369939
|
|
|
|
|
|
|
|
|
| |
We have started to see the no_binary version of this test
fail. The reason is that the binary was being removed
before the spawn actually launched the inferior. Add a
simple filesystem based synchronization to avoid this race.
llvm-svn: 369930
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch dotest.py will print the full invocation whenever it
fails to parse its arguments. The dotest invocation is usually build up
with different inputs, potentially coming from CMake, lldb-dotest, lit
or passed directly. This can make debugging hard, especially on CI,
where there might be another layer of indirection. This aims to make
that a bit easier.
llvm-svn: 369922
|
|
|
|
|
|
|
|
| |
My previous attempt in attempt in r369904 actually broke the 32bit build
because File::Read expects to take a reference to size_t. Fix the
warning by using SIZE_MAX to denote failure instead.
llvm-svn: 369910
|
|
|
|
| |
llvm-svn: 369908
|
|
|
|
|
|
| |
The class under test was moved in r355342. This moves the test code too.
llvm-svn: 369907
|
|
|
|
|
|
|
| |
Don't attempt to print invalid user ids. Previously, these would come
out as UINT32_MAX, or as an assertion failure.
llvm-svn: 369906
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
GetU64 returns a uint64_t. Don't store it in size_t as that is only
32-bit on 32-bit platforms.
llvm-svn: 369904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 should always have a dummy target, so we might as well construct it directly when we create a Debugger object.
The idea is that if this patch doesn't cause any problems that we can get rid of all the logic
that handles situations where we don't have a dummy target (as all that code is currently
untested as there seems to be no way to have no dummy target in LLDB).
Reviewers: labath, jingham
Reviewed By: labath, jingham
Subscribers: jingham, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66581
llvm-svn: 369885
|
|
|
|
| |
llvm-svn: 369880
|
|
|
|
| |
llvm-svn: 369827
|
|
|
|
|
|
| |
rdar://problem/54656572
llvm-svn: 369821
|
|
|
|
|
|
|
|
|
|
|
|
| |
On macOS one Mach-O slice can contain multiple load commands: One load
command for being loaded into a macOS process and one load command for
being loaded into a macCatalyst process. This patch adds support for
the new load command and makes sure ObjectFileMachO returns the
Architecture that matches the Module.
Differential Revision: https://reviews.llvm.org/D66626
llvm-svn: 369814
|
|
|
|
|
|
|
|
|
|
| |
STATUS_SINGLE_STEP and STATUS_BREAKPOINT are defined as 0x8------ which
is negative and thus can't be implicitly narrowed to a DWORD which is
unsigned. The value is defined differently across winnt.h and ntstatus.h.
Patch by Gwen Mittertreiner!
llvm-svn: 369788
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes DeclVendor's dependency on clang (and ClangASTContext).
DeclVendor has no need to know about specific TypeSystems.
Differential Revision: https://reviews.llvm.org/D66628
llvm-svn: 369735
|
|
|
|
|
|
|
| |
This patch addresses Adrian McCarthy's code review feedback in
https://reviews.llvm.org/D66447
llvm-svn: 369731
|
|
|
|
| |
llvm-svn: 369712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
This reapplies r369690 with a previously missing constructor for LanguageSet.
llvm-svn: 369710
|
|
|
|
|
|
|
|
| |
It looks like running without this argument was supported
for legacy reasons, but a Xcode 11 beta made the argument
mandatory for our usecase.
llvm-svn: 369709
|
|
|
|
|
|
|
|
| |
This reverts r369684 (git commit cc62e38d258f414c196b566374c606e83a85a034)
Adding a declaration doesn't appear to be a sufficient fix.
llvm-svn: 369706
|
|
|
|
|
|
| |
This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f)
llvm-svn: 369702
|
|
|
|
|
|
| |
lldb/source/Interpreter/OptionValueFileSpecList.cpp (NFC)
llvm-svn: 369699
|
|
|
|
|
|
| |
lldb/source/Interpreter/OptionValueFileSpecListTmp.cpp (NFC)
llvm-svn: 369698
|
|
|
|
| |
llvm-svn: 369692
|
|
|
|
| |
llvm-svn: 369691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
llvm-svn: 369690
|
|
|
|
|
|
|
|
| |
The evaluation context isn't guaranteed to have this declaration.
Fixes "error: use of undeclared identifier 'malloc_get_all_zones'" bugs.
llvm-svn: 369684
|
|
|
|
| |
llvm-svn: 369670
|
|
|
|
| |
llvm-svn: 369669
|
|
|
|
|
|
| |
That ')' slipped in by accident in the reformatting commit.
llvm-svn: 369660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since D66174 I see failures of TestDataFormatterStdList in about 50% of runs on
Fedora 30 x86_64 libstdc++. I have found out that LLDB internally expects these
RegularExpressions to be matched in their alphabetical order:
^std::(__cxx11::)?list<.+>(( )?&)?$
^std::__[[:alnum:]]+::list<.+>(( )?&)?$
But since D66174 they are sometimes matched in reverse order. In fact it was
only some luck it worked before as there is internally
std::map<lldb::RegularExpressionSP, FormatterImpl> (FormattersContainer).
Differential Revision: https://reviews.llvm.org/D66398
llvm-svn: 369655
|
|
|
|
| |
llvm-svn: 369652
|
|
|
|
| |
llvm-svn: 369646
|
|
|
|
| |
llvm-svn: 369635
|
|
|
|
| |
llvm-svn: 369632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).
This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66522
llvm-svn: 369625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remove any undocumented/redundant return values
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
|
|
|
|
|
|
|
| |
We cannot use llvm::once_flag in debugserver because doesn't link
against llvm.
llvm-svn: 369621
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The former seems like it's not working on some platforms.
All the other uses use `llvm::`, so, let's change for consistency.
Reviewers: jasonmolenda, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66566
llvm-svn: 369618
|
|
|
|
|
|
|
| |
The format info entries need to match the order of the enum entries.
This should fix the two failing data-formatter tests.
llvm-svn: 369617
|
|
|
|
|
|
|
|
| |
This adds a static assert that ensures that there's a format info entry
for every format enum value. This should prevent others from making the
same mistake I made and Jason kindly fixed in r369611. (Thanks!)
llvm-svn: 369614
|