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:
Using a BreakpointList corrupts the breakpoints' IDs because
BreakpointList::Add sets the ID, so use a vector instead, and
update the signature to return the vector wrapped in an
llvm::Expected which can propagate any error from the inner
call to StringIsBreakpointName.
Note that, despite the similar name, SBTarget::FindBreakpointsByName
doesn't suffer the same problem, because it uses a SBBreakpointList,
which is more like a BreakpointIDList than a BreakpointList under the
covers.
Add a check to TestBreakpointNames that, without this fix, notices the
ID getting mutated and fails.
Reviewers: jingham, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70907
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:
Previously the ABI plugin exposed some "register infos" and the
gdb-remote code used those to fill in the missing bits. Now, the
"filling in" code is in the ABI plugin itself, and the gdb-remote code
just invokes that.
The motivation for this is two-fold:
a) the "augmentation" logic is useful outside of process gdb-remote. For
instance, it would allow us to avoid repeating the register number
definitions in minidump code.
b) It gives more implementation freedom to the ABI classes. Now that
these "register infos" are essentially implementation details, classes
can use other methods to obtain dwarf/eh_frame register numbers -- for
instance they can consult llvm MC layer.
Since the augmentation code was not currently tested anywhere, I took
the opportunity to create a simple test for it.
Reviewers: jasonmolenda, clayborg, tatyana-krasnukha
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70906
Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.
rdar://57094085
Differential Revision: https://reviews.llvm.org/D70100
Summary: Ensure that breakpoint ivar is properly set in exception breakpoint resolver so that exception breakpoints set on dummy targets are resolved once real targets are created and run.
Reviewers: jingham
Reviewed By: jingham
Subscribers: teemperor, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69880
Summary:
The permissions in a memory region have ternary states (yes, no, don't
know), but the memory region command only prints in binary, treating
"don't know" as "yes", which is particularly confusing as for instance
the unwinder will treat an unknown value as "no".
This patch makes is so that we distinguish all three states when
printing the values, using "?" to indicate the lack of information. It
is implemented via a special argument to the format provider for the
OptionalBool enumeration.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69106
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
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:
This patch re-types everywhere that passes a File::OpenOptions
as a uint32_t so it actually uses File::OpenOptions.
It also converts some OpenOptions related functions that fail
by returning 0 or NULL into llvm::Expected
split off from https://reviews.llvm.org/D68737
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68853
llvm-svn: 374817
Summary:
The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and that also changes its name
from one file to the other (either `containing` and `complete`). It was added in the original LLDB check in, so there isn't any history what
this was supposed to be, so let's just remove it.
Reviewers: jingham, JDevlieghere, labath
Reviewed By: jingham, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68696
llvm-svn: 374313
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
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
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
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
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
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
Summary:
InferiorCall is only ever used in Process, and it is not specific to
POSIX. By moving it to Process, we can remove all dependencies on plugins from
Process. Moving InferiorCall to Process seems to achieve this quite well.
Additionally, the name InferiorCall is a little vague now, so we rename
it something a bit more specific.
Reviewers: JDevlieghere, clayborg, compnerd, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67472
llvm-svn: 371796
Summary:
We got a radar that printing small floats is not very user-friendly in LLDB as we print them with up to
100 leading zeroes before starting to use scientific notation. This patch changes this by already using
scientific notation when we hit 6 padding zeroes by default and moves this value into a target setting
so that users can just set this number back to 100 if they for some reason preferred the old behaviour.
This new setting is influencing how we format data, so that's why we have to reset the data visualisation
cache when it is changed.
Note that we have always been using scientific notation for large numbers because it seems that
the LLVM implementation doesn't support printing out the padding zeroes for them. I would have fixed
that if it was trivial, but looking at the LLVM implementation for this it seems that this is not as trivial
as it sounds. I would say we look into this if we ever get a bug report about someone wanting to have
a large amount of trailing zeroes in their numbers instead of using scientific notation.
Fixes rdar://39744137
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67001
llvm-svn: 370880
There is now std::shared_ptr passed around which is expensive for manycore
CPUs. Most of the times (except for 3 cases) it is now just std::moved with no
CPU locks needed. It also makes it possible to sort the keys (which is now not
needed much after D66398).
Differential revision: https://reviews.llvm.org/D67049
llvm-svn: 370863
Remove the single instance of std::call_once() in lldbTarget library
with llvm::call_once(). The former fails to build on NetBSD when
combined with llvm::once_flag (which replaced std::once_flag
in r369618), and combining the two is probably generally incorrect
anyway.
llvm-svn: 370748
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
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
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
I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI
as an advantage and there is already constructor parameter to compile the
regex.
Differential Revision: https://reviews.llvm.org/D66392
llvm-svn: 369352
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
There was a little bit of logic in the StopInfoBreakpoint::PerformAction
that would null out the StopInfo once we had a completed plan so that the
next call to GetStopInfo would replace it with the StopInfoThreadPlan.
But the stop-hooks check for whether a thread stopped for a reason didn't
trigger this conversion. So I added an API to do that directly, and then
called it where before we just reset the StopInfo.
<rdar://problem/54270767>
Differential Revision: https://reviews.llvm.org/D66241
llvm-svn: 369052
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
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
Adrian's changes to support Catalyst processes and my
changes to support debugserver running on an arm64_32
device (Apple Watch Series 4, which uses an IPL32 model
on arm64 cpus).
llvm-svn: 368118
This function is not portable, and there are only a handful of usages of
it anyway. Replacing it with std::this_thread::sleep_for enables us to
get rid of the compatibility code in PosixApi.h.
llvm-svn: 367814
Summary:
Update StackFrame::GetSymbolContext to mirror the logic in
RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the
pc decrement when the given frame is a signal trap handler frame or the
parent of one, because the pc may not follow a call in these frames.
Accomplish this by adding a behaves_like_zeroth_frame field to
lldb_private::StackFrame, set to true for the zeroth frame, for
signal handler frames, and for parents of signal handler frames.
Also add logic to propagate the signal handler flag from UnwindPlan to
the FrameType on the RegisterContextLLDB it generates, and factor out a
helper to resolve symbol and address range for an Address now that we
need to invoke it in four places.
Reviewers: jasonmolenda, clayborg, jfb
Reviewed By: jasonmolenda
Subscribers: labath, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64993
llvm-svn: 367691
Reformat OptionEnumValueElement to make it easier to distinguish between
its fields. This also removes the need to disable clang-format for these
arrays.
Differential revision: https://reviews.llvm.org/D65489
llvm-svn: 367638
Summary:
The methods to find types in a Target aren't clang specific and are
pretty generalizable to type systems. Additionally, to support some of
the use cases in SBTarget, I've added a "GetScratchTypeSystems" method
to Target to support getting all type systems for a target we are
debugging.
Differential Revision: https://reviews.llvm.org/D64964
llvm-svn: 367480
