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
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
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
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 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
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 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 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
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
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
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
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
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
enum Format entries; else we can crash in a place like
FormatManager::GetFormatAsCString(). We should add bounds checks
to prevent this more reliably, but for tonight I'm just adding this
entry to keep an address-sanitizer test run working.
llvm-svn: 369611
Jason Molenda