| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
This patch replaces the hand-rolled JSON decoding in StructuredData with
LLVM's JSON library.
Differential revision: https://reviews.llvm.org/D68282
llvm-svn: 373360
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 373355
|
|
|
|
| |
llvm-svn: 373354
|
|
|
|
| |
llvm-svn: 373353
|
|
|
|
| |
llvm-svn: 373352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is untested, I don't have access to a Windows machine.
llvm-svn: 373342
|
|
|
|
|
|
|
| |
Given that we can implicitly construct a ClangASTContext from any string, we should
really mark this as explicit.
llvm-svn: 373339
|
|
|
|
|
|
| |
This code isn't used nor tested.
llvm-svn: 373337
|
|
|
|
|
|
| |
the ExternalASTSource
llvm-svn: 373334
|
|
|
|
|
|
|
|
|
|
|
| |
construction.
We have no use case in LLDB where we actually do want to change the ASTContext after
it the ClangASTContext has been constructed. All callers of setASTContext are just setting
the ASTContext directly after construction, so we might as well make this a Constructor
instead of supporting this tricky use case.
llvm-svn: 373330
|
|
|
|
|
|
|
|
|
| |
Now using default initializers and StringRef.
Also formats the member list that we excluded from clang-format
at some point and still hangs around with the old LLDB code style.
llvm-svn: 373329
|
|
|
|
|
|
| |
NFC preparation work for upcoming ExternalASTMerger patches.
llvm-svn: 373312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch adds support of watchpoints to the new `NativeProcessWindows` plugin. The same tests as in D67168 pass with these changes when the old plugin is turned off, so they will cover this functionality when the old plugin is gone.
Reviewers: asmith, amccarth, stella.stamenova, labath
Reviewed By: labath
Subscribers: labath, jfb, JDevlieghere, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67222
llvm-svn: 373300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
File::Clear() is an ugly function. It's only used in one place,
which is the swig typemaps for FILE*. This patch refactors and
renames that function to make it clear what it's really for and
why nobody else should use it.
Both File::TakeStreamAndClear() and the FILE* typemaps will be
removed in later patches after a suitable replacement is in place.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68160
llvm-svn: 373285
|
|
|
|
|
|
|
|
|
|
|
| |
It is always doing work on behalf of another thread that presumably
has the mutex, so if it is calling SB API's it should have free access
to the mutex. This is the same decision as we made earlier with the
process RunLock.
Differential Revision: https://reviews.llvm.org/D68174
llvm-svn: 373280
|
|
|
|
|
|
| |
This adds some information on how to instrument the API classes.
llvm-svn: 373277
|
|
|
|
| |
llvm-svn: 373267
|
|
|
|
| |
llvm-svn: 373250
|
|
|
|
|
|
|
| |
I think a reasonable plan here is to add support for OSes following the
SysV ABI one by one, watching the bots as we go.
llvm-svn: 373233
|
|
|
|
|
|
|
| |
Summary:
D67966 changes the output when dumping DWARF expressions and this updates basic_entry_values_x86_64 test to reflect this change.
llvm-svn: 373229
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTypes would yield only the very last set of results), but instead
of fixing it, removing it seemed like an even better option.
rdar://problem/54412692
Differential Revision: https://reviews.llvm.org/D68171
llvm-svn: 373224
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This was originally a 'do { ... } while (false);' like in the rest
of the function, but the do was refactored into an 'if' without
also removing the trailing 'while(false);'
llvm-svn: 373206
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the option parser
The problem with r370734 was that it removed the code for resetting the options in
OptionParsingStarting. This caused that once a 'frame select -r ...' command was executed,
we kept the relative index argument for all following 'frame select ...' invocations (even
the ones with an absolute index as they are the same command object). See rdar://55791276.
This relands the patch but keeps the code that resets the command options before execution.
llvm-svn: 373201
|
|
|
|
|
|
|
|
|
|
|
| |
breaks the option parser
This somehow caused that 'frame select X' ends up being interpreted as 'frame select -r 1' when 'up' or 'down'
were run before 'frame select X'. See rdar://55791276.
Partly reverting to unbreak master. The changes that aren't reverted are the generic 'frame select -r' tests
that are obviously NFC and test existing behavior.
llvm-svn: 373194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExternalASTMerger
Summary:
The ExternalASTMerger should use the ASTImporterSharedState. This allows it to
handle std::pair in LLDB (but the rest of libc++ is still work in progress).
Reviewers: martong, shafik, a.sidorin
Subscribers: rnkovacs, christof, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68140
llvm-svn: 373193
|
|
|
|
|
|
|
|
|
| |
dbghelp api. NFC."
This reverts SVN r373144, as it changed the demangled output a little, see
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9306.
llvm-svn: 373146
|
|
|
|
|
|
|
|
|
| |
If there's any testcases that only do demangling (I didn't find any),
they could be made available for all platforms now.
Differential Revision: https://reviews.llvm.org/D68134
llvm-svn: 373144
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D68173
llvm-svn: 373135
|
|
|
|
| |
llvm-svn: 373134
|
|
|
|
|
|
|
|
|
|
|
| |
When not running under a TTY the output is buffered and not flushed
before debugserver exits which makes it impossible to parse the version
string. This adds a -V/--version command that just prints the version to
stdout and exits with an exit code zero.
Differential revision: https://reviews.llvm.org/D68156
llvm-svn: 373127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
m_should_close_fd doesn't need to be in IOObject. It will be useful
for my next change to move it down into File and Socket.
Reviewers: labath, JDevlieghere, jasonmolenda
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68152
llvm-svn: 373126
|
|
|
|
|
|
| |
This should be a valid absolute path on both POSIX and Windows.
llvm-svn: 373124
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The ClangDriverOptions target is not available for standalone builds.
Thanks Alex for pointing this out!
llvm-svn: 373112
|
|
|
|
|
|
|
|
|
|
| |
Revert: llvm-svn: 373061
It broke OSX testsuite:
https://reviews.llvm.org/D67589#1686150
lldb/packages/Python/lldbsuite/test/macosx/function-starts/TestFunctionStarts.py
llvm-svn: 373110
|
|
|
|
|
|
|
|
| |
ModuleList.cpp includes clang/Driver/Driver.h which depends on
clang/Driver/Options.inc. This patch adds the corresponding TableGen
target to Core.
llvm-svn: 373105
|
|
|
|
|
|
|
|
|
|
|
| |
The VFS requires files to be have absolute paths. The file collector
makes paths relative to the reproducer root. If the root is a relative
path, this would trigger an assert in the VFS. This patch ensures that
we always make the given path absolute.
Thank you Ted Woodward for pointing this out!
llvm-svn: 373102
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
|
|
|
|
|
|
| |
The D67717 excludes such locations for now.
llvm-svn: 373074
|
|
|
|
|
|
|
|
| |
ModuleList.cpp includes clang/Driver/Driver.h. Reflect that in the build
system. Not having this can cause build failures if ModuleList.cpp is
built before Driver.inc is generated.
llvm-svn: 373073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Windows unwinding is weird. The unwind rules do not (always) describe
the precise layout of the stack, but rather expect the debugger to scan
the stack for something which looks like a plausible return address, and
the unwind based on that. The reason this works somewhat reliably is
because the the unwinder also has access to the frame sizes of the
functions on the stack. This allows it (in most cases) to skip function
pointers in local variables or function arguments, which could otherwise
be mistaken for return addresses.
Implementing this kind of unwind mechanism in lldb was a bit challenging
because we expect to be able to statically describe (in the UnwindPlan)
structure, the layout of the stack for any given instruction. Giving a
precise desription of this is not possible, because it requires
correlating information from two functions -- the pushed arguments to a
function are considered a part of the callers stack frame, and their
size needs to be considered when unwinding the caller, but they are only
present in the unwind entry of the callee. The callee may end up being
in a completely different module, or it may not even be possible to
determine it statically (indirect calls).
This patch implements this functionality by introducing a couple of new
APIs:
SymbolFile::GetParameterStackSize - return the amount of stack space
taken up by parameters of this function.
SymbolFile::GetOwnFrameSize - the size of this function's frame. This
excludes the parameters, but includes stuff like local variables and
spilled registers.
These functions are then used by the unwinder to compute the estimated
location of the return address. This address is not always exact,
because the stack may contain some additional values -- for instance, if
we're getting ready to call a function then the stack will also contain
partially set up arguments, but we will not know their size because we
haven't called the function yet. For this reason the unwinder will crawl
up the stack from the return address position, and look for something
that looks like a possible return address. Currently, we assume that
something is a valid return address if it ends up pointing to an
executable section.
All of this logic kicks in when the UnwindPlan sets the value of CFA as
"isHeuristicallyDetected", which is also the final new API here. Right
now, only SymbolFileBreakpad implements these APIs, but in the future
SymbolFilePDB will use them too.
Differential Revision: https://reviews.llvm.org/D66638
llvm-svn: 373072
|
|
|
|
|
|
|
| |
This check was failing since it was added in r372837. It should be
possible to re-enable it once D68010 lands.
llvm-svn: 373071
|
|
|
|
|
|
|
|
|
| |
Previously, these were unseen because the wrapper script would swallow
them. This fixes the following types of warnings:
- methods being declared more than once
- swig complained about ignoring operator=, so I just removed it
llvm-svn: 373069
|
|
|
|
|
|
|
| |
According to a comment by Pavel Labath:
https://reviews.llvm.org/D67589#inline-612375
llvm-svn: 373061
|
|
|
|
| |
llvm-svn: 373053
|
|
|
|
| |
llvm-svn: 373051
|
|
|
|
|
|
|
|
| |
A lot of commands are made up of CommandObjectMultiword with
subcommands. CommandObjectMultiword actually has some functionality
on its own that wasn't tested before.
llvm-svn: 373050
|