| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 373267
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The ClangDriverOptions target is not available for standalone builds.
Thanks Alex for pointing this out!
llvm-svn: 373112
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 373053
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 372998
|
|
|
|
|
|
|
|
|
|
|
|
| |
A simplification for D67589. m_opaque_up can never be nullptr (unless one calls
a ctor with nullptr or one uses SetLLDBObjectPtr with nullptr).
Also protected SetLLDBObjectPtr is not used anywhere (I haven't found it would
ever be used).
Differential revision: https://reviews.llvm.org/D68083
llvm-svn: 372976
|
|
|
|
|
|
|
| |
There is no ClangModulesDeclVendor on Linux so that cast is triggering an assert.
Let's just remove it as it just casts the type to itself.
llvm-svn: 372974
|
|
|
|
|
|
|
|
| |
Summary: Usually, SIGINT and SIGSTOP don't imply a crash, e.g. SIGSTOP is sent on process launch and attach on some platforms.
Differential Revision: https://reviews.llvm.org/D67776
llvm-svn: 372961
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids having to define additional macros in the cmake file, and
and also makes the logic in the cpp files more compact. It is also
easily extendible to other plugin types (instruction emulation?) that
should only be initialized if the corresponding llvm target is built.
Thanks to Ilya Birukov for pointing me to this file.
llvm-svn: 372952
|
|
|
|
|
|
|
|
| |
We now have a utility function for this purpose.
(Also fixing the typo in the related comment while I'm at it.)
llvm-svn: 372946
|
|
|
|
|
|
| |
Now that dw_tag_t is an enum, a default case is required.
llvm-svn: 372920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB synthesizes decls using asm labels. These decls cannot have a mangle
different than the one specified in the label name. I.e., the '\01' prefix
should not be added.
Fixes an expression evaluation failure in lldb's TestVirtual.py on iOS.
rdar://45827323
Differential Revision: https://reviews.llvm.org/D67774
llvm-svn: 372903
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently dw_tag_t is a typedef for uint16_t. This patch changes makes
dw_tag_t a typedef for llvm::dwarf::Tag. This enables us to use the full
power of the DWARF utilities in LLVM without having to do the cast every
time. With this approach, we only have to do the cast when reading the
ULEB value.
Differential revision: https://reviews.llvm.org/D68005
llvm-svn: 372891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I was recently surprised to learn that there is a total of 2 (two) users
of the register info definitions contained in the ABI plugins. Yet, the
defitions themselves span nearly 10kLOC.
The two users are:
- dwarf expression pretty printer
- the mechanism for augmenting the register info definitions obtained
over gdb-remote protocol (AugmentRegisterInfoViaABI)
Both of these uses need the DWARF an EH register numbers, which is
information that is already available in LLVM. This patch makes it
possible to do so.
It adds a GetMCRegisterInfo method to the ABI class, which every class
is expected to implement. Normally, it should be sufficient to obtain
the definitions from the appropriate llvm::Target object (for which I
provide a utility function), but the subclasses are free to construct it
in any way they deem fit.
We should be able to always get the MCRegisterInfo object from llvm,
with one important exception: if the relevant llvm target was disabled
at compile time. To handle this, I add a mechanism to disable the
compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD
cmake setting. This ensures all our existing are able to create their
MCRegisterInfo objects.
The new MCRegisterInfo api is not used yet, but the intention is to make
use of it in follow-up patches.
Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha
Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits
Differential Revision: https://reviews.llvm.org/D67965
llvm-svn: 372862
|
|
|
|
|
|
|
|
|
|
| |
GetRawLineUntilCursor
They both return the same result as another function (GetCursorArgumentPrefix
and GetRawLine). They were only added because the old API allowed to look
(in theory) behind the cursor position which is no longer possible.
llvm-svn: 372861
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The cursor position is always at the end of the current argument (as the
argument cut off after the cursor position). So this code is a no-op and
can be removed.
llvm-svn: 372851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Use symbolic constants for the platform identifiers rather than replicating them
> locally.
This broke the build of LLDB on Windows, see
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9182 which
fails with e.g.
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(96): error C2059: syntax error: 'constant'
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(96): error C3805: 'constant': unexpected token, expected either '}' or a ','
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(128): error C2059: syntax error: 'constant'
...
llvm-svn: 372847
|
|
|
|
|
|
|
|
| |
In top level expressions, we don't have a m_source_code and we don't need to change
the source bounds (as no wrapping happend there). Fixes the test on the
sanitizer bot.
llvm-svn: 372817
|
|
|
|
|
|
|
|
|
|
|
| |
ResetOutputFileHandle() isn't being used by anything. Also it's using
FILE*, which is something we should be doing less of. Remove it.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D68001
llvm-svn: 372800
|
|
|
|
|
|
|
| |
Use symbolic constants for the platform identifiers rather than replicating them
locally.
llvm-svn: 372788
|
|
|
|
| |
llvm-svn: 372763
|
|
|
|
|
|
|
|
|
| |
Fix NativeProcessNetBSD::Resume() to handle LLDB_INVALID_SIGNAL_NUMBER
correctly. Fixes breakage caused by r372090 and r372300. I have major
rewrite of that function pending; however, the fixes to gdb-remote
were committed prior to that.
llvm-svn: 372755
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a test case for the change from SVN r372657, and for the
preexisting ARM identification.
Add a missing ArchDefinitionEntry for PECOFF/arm64, and tweak
the ArmNt case to set the architecture to armv7 (ArmNt never ran
on anything lower than that). (This avoids a case where
ArchSpec::MergeFrom would override the arch from arm to armv7 and
ArchSpec::CoreUpdated would reset the OS to unknown at the same time.)
Differential Revision: https://reviews.llvm.org/D67951
llvm-svn: 372741
|
|
|
|
|
|
|
|
|
| |
In these cases, the register number should be calculated from
fpu_d0, not fpu_s0.
Differential Revision: https://reviews.llvm.org/D67892
llvm-svn: 372738
|
|
|
|
|
|
| |
That's what we actually want to do. Might fix the Windows bot.
llvm-svn: 372729
|
|
|
|
| |
llvm-svn: 372724
|