This patch adds an overload to serialize and deserialize char** types.
This is necessary for things like the SBLaunchInfo ctor. We serialize
the array length followed by each individual item.
Only the templated function had logging for deserialization. The string
deserializer is implemented as a specialization and now prints to the
log as well.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
Different buffering behavior during capture and replay caused some of
the shell tests to fail when run from a reproducer. By disabling stdout
buffering we get a better approximation of how things get flushed during
an regular debug session. There is a performance impact but since this
only affects replay this is acceptable.
Add a flag which always generates a reproducer when normally it would be
discarded. This is meant for testing purposes to capture a debugger
session without modification the session itself.
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
llvm_unreachable is marked noreturn so the compiler can assume the code
for printing the error message in release builds isn't hit which defeats
the purpose.
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
It's not up to YAML to validate the semantics of the GDB remote packet
struct. This is especially wrong here as there's nothing that says that
the amount of bytes transmitted matches the packet payload size.
When running the test suite with always capture on, a handful of tests
are failing because they have multiple targets and therefore multiple
GDB remote connections. The current reproducer infrastructure is capable
of dealing with that.
This patch reworks the GDB remote provider to support multiple GDB
remote connections, similar to how the reproducers support shadowing
multiple command interpreter inputs. The provider now keeps a list of
packet recorders which deal with a single GDB remote connection. During
replay we rely on the order of creation to match the number of packets
to the GDB remote connection.
Differential revision: https://reviews.llvm.org/D71105
GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit. So this replacing it with a explicit cast and refactors the code around it to use an early exit.
Differential Revision: https://reviews.llvm.org/D70992
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:
This patch fixes a bug where when target triple created from elf information
is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging
both triple results in armv8l--unknown-unknown.
This happens because we order a triple update while calling CoreUpdated and
CoreUpdated creates a new triple with no vendor or environment information.
Making sure we do not update triple and just update to more specific core
fixes the issue.
Reviewers: labath, jasonmolenda, clayborg
Reviewed By: jasonmolenda
Subscribers: jankratochvil, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70155
Make it possible to override reproducer capture with the
LLDB_CAPTURE_REPRODUCER environment variable.
The goal of this change is twofold.
(1) I want to be able to enable capturing reproducers during regular
test runs, both locally and on the bots. To do so I need a way to
force capture. I cannot do this through the Python API, because
reproducer capture must be enabled *before* the debugger
initialized, which happens automatically when doing `import lldb`.
(2) I want to provide an escape hatch for when reproducers are enabled
by default. Downstream we have reproducer capture enabled by default
in the driver.
This patch solves both problems by overriding the reproducer mode based
on the environment variable. Acceptable values are 0/1 and ON/OFF.
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
Windows on ARM always uses thumb mode, and doesn't have most of the
mechanisms that are used in e.g. ELF for distinguishing between arm
and thumb.
Differential Revision: https://reviews.llvm.org/D70796
Summary:
I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.
Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.
Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70241
This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores.
This was needed because on Linux running on 32-bit Arm v8 we are returned
armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit
kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l.
This is quite common when we run 32 bit arm using docker container.
Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>
Differential Revision: https://reviews.llvm.org/D69904
gcc-9 started warning when a class defined a copy constructor without a
copy assignment operator (or vice-versa).
This fixes those warnings by deleting the other special member too
(after verifying it doesn't do anything non-trivial).
As discussed in https://reviews.llvm.org/D68549, the actual issue
here seems to be that the BumpPtrAllocator is growing far too slow
because of the 256 different StringPools used as the backend for ConstString.
At the same time the original patch made ConstString allocate memory in
256MiB slabs for the same reason, meaning that the RSS usage of LLDB increased
by a few hundred MiB for all users without bringing any noticeable speedup
for most of them.
llvm-svn: 375062
This patch extends the reproducer to capture the debugger's current
working directory. This information will be used later to set the
current working directory of the VFS.
llvm-svn: 375059
BumpPtrAllocator allocates in 4KiB chunks, which with any larger
project is going to result in a large number of allocations.
Increasing allocation size this way can save 10%-20% of symbol
load time for a huge C++ project with correctly built debuginfo.
Differential Revision: https://reviews.llvm.org/D68549
llvm-svn: 374583
Summary:
The previous attempt at making nameless process not match when searching for a
given name failed because the macos implementation was depending on this detail
in its partial matching strategy. Doing partial matching to avoid expensive
lookups is a perfectly valid thing to do, the way it was implemented seems
somewhat unexpected.
This patch implements it differently by providing special
methods in the ProcessInstanceInfoMatch which match only a subset of fields,
and changes mac host code to use those instead.
Then, it re-applies r373925 to get make the ProcessInstanceInfoMatch with a
name *not* match a nameless process.
Reviewers: JDevlieghere, teemperor, jingham
Subscribers: wallace, lldb-commits
Differential Revision: https://reviews.llvm.org/D68631
llvm-svn: 374529
Summary:
The `if (*cstr_end == '\0')` in the previous code checked if the previous loop terminated because it
found a null terminator or because it reached the end of the data. However, in the case that we hit
the end of the data before finding a null terminator, `cstr_end` points behind the last byte in our
data and `*cstr_end` reads the memory behind the array (which may be uninitialised)
This patch just rewrites that function use `std::find` and adds the relevant unit tests.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68773
llvm-svn: 374311
Since D68289, a couple of tests on linux started being extremely flaky.
All of them were doing name-based attaching and were failing because
they couldn't find an unambiguous process to attach to.
The patch above changed the process finding logic, so that failure to
find a process name does not constitute an error. This meant that a lot
more transient processes showed up in the process list during the test
suite run. Previously, these processes would not appear as they would be
gone by the time we went to read their executable name, arguments, etc.
Now, this alone should not cause an issue were it not for the fact that
we were considering a process with no name as if it matched by default
(even if we were explicitly searching for a process with a specified
name). This meant that any of the "transient" processes with no name
would make the name match ambiguous. That clearly seems like a bug to me
so I fix that.
llvm-svn: 373925
This patch is the final step in my quest to get rid of the JSON parser
in LLDB. Vedant's coverage report [1] shows that it was mostly untested.
Furthermore, the LLVM implementation has a much nicer API and using it
means one less thing to maintain for LLDB.
[1] http://lab.llvm.org:8080/coverage/coverage-reports/index.html
Differential revision: https://reviews.llvm.org/D68305
llvm-svn: 373501
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
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
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
We currently have two lists in the CompletionRequest that we
inherited from the old API: The complete list of arguments ignoring
where the user requested completion and the list of arguments that
stops at the cursor. Having two lists of arguments is confusing
and can lead to subtle errors, so let's remove the complete list
until we actually need it.
llvm-svn: 372692
These ifdefs contain code that isn't specific to MSVC but useful for
any windows target, like MinGW.
Differential Revision: https://reviews.llvm.org/D67893
llvm-svn: 372592
The fact that index==-1 means "no arguments" is not obvious and only
used in one place from what I can tell. Also fixes several warnings
about using the cursor index as if it was a size_t when comparing.
Not fully NFC as we now also correctly update the partial argument list
when injecting the fake empty argument in the CompletionRequest
constructor.
llvm-svn: 372566
This moves the dumping logic from the GDBRemoteCommunicationHistory
class into the GDBRemotePacket so that it can be reused from the
reproducer command object.
llvm-svn: 372028
To support dumping the reproducer's GDB remote packets, we need the
(de)serialization logic to live in Utility rather than the GDB remote
plugin. This patch renames StreamGDBRemote to GDBRemote and moves the
relevant packet code there.
Its uses in the GDBRemoteCommunicationHistory and the
GDBRemoteCommunicationReplayServer are updated as well.
Differential revision: https://reviews.llvm.org/D67523
llvm-svn: 371907
The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.
llvm-svn: 371842
This code is not on any performance critical path that would
justify this shortening optimization. It also makes it possible
to turn 'ref' into a function (as this is the only place where
we modify this ArgEntry member).
llvm-svn: 371836
This just moves the CommandLoader utility into the reproducer namespace
and makes it accessible outside the API layer. This is setting things up
for a bigger change.
llvm-svn: 371689
Originally the idea was for providers to be defined close to where they
are used. While this helped designing the providers in such a way that
they don't depend on each other, it also means that it's not possible to
access them from a central place. This proved to be a problem for some
providers and resulted in them living in the reproducer class.
The ProcessGDBRemote provider is the last remaining exception. This
patch makes things consistent and moves it into the reproducer like the
other providers.
llvm-svn: 371685
This patch adds basic support for DW_OP_convert[1] for integer
types. Recent versions of LLVM's optimizer may insert this opcode into
DWARF expressions. DW_OP_convert is effectively a type cast operation
that takes a reference to a base type DIE (or zero) and then casts the
value at the top of the DWARF stack to that type. Internally this
works by changing the bit size of the APInt that is used as backing
storage for LLDB's DWARF stack.
I managed to write a unit test for this by implementing a mock YAML
object file / module that takes debug info sections in yaml2obj
format.
[1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1
<rdar://problem/48167864>
Differential Revision: https://reviews.llvm.org/D67369
llvm-svn: 371532
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
The implementation of this function was obviously incorrect, as the
result variable was never used. This led me to check if it was actually
used anywhere, which came back negative.
llvm-svn: 369492
While generating the Doxygen I noticed this lone namespace that has one
class and one function in it. This moves them into lldb_private.
llvm-svn: 369485
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
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
Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.
llvm-svn: 367385
When investigating a completion bug I got confused by the API.
LongestCommonPrefix finds the longest common prefix of the strings in
the string list. Instead of returning that string through an output
argument, just return it by value.
llvm-svn: 367384
The file collector class is useful for creating reproducers,
not just for LLDB, but for other tools as well in LLVM/Clang.
Differential Revision: https://reviews.llvm.org/D65237
llvm-svn: 366956
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
This patch removes any remaining instances of LogIfAnyCategoriesSet and
replaces them with the LLDB_LOG macro. This in turn made it possible to
make Log::VAPrintf and Log::VAError private.
llvm-svn: 366768
We had a long discussion in D59911 about lldb_assert and what it means.
The result was the assert manifesto on lldb.llvm.org.
> LLDB provides lldb_assert() as a soft alternative to cover the middle
> ground of situations that indicate a recoverable bug in LLDB. In a
> Debug configuration lldb_assert() behaves like assert(). In a Release
> configuration it will print a warning and encourage the user to file a
> bug report, similar to LLVM’s crash handler, and then return
> execution.
However, currently lldb_assert doesn't behave they way it's being
described there: it doesn't abort in a debug/assert build. This patch
fixes that by adding a call to assert() in lldb_assert().
Differential revision: https://reviews.llvm.org/D64267#1571962
llvm-svn: 365246
Copy over access and modification time for the files included in the
reproducer. This is needed to pass tests that check the integrity of
object files based on their time stamp.
llvm-svn: 364457
Before this patch, reproducers weren't relocatable. The reproducer
contained hard coded paths in the VFS mapping, as well in the yaml file
listing the different input files for the command interpreter. This
patch changes that:
- Use relative paths for the DataCollector.
- Use an overlay prefix for the FileCollector.
Differential revision: https://reviews.llvm.org/D63467
llvm-svn: 363697
Utility doesn't link against lldbBase so we cannot call GetVersion in
keep. I already added a string member m_version to deal with that, but
the call was still there.
llvm-svn: 363228
Generally, reproducers are rev-locked to the version of LLDB, so it's
valuable to have the LLDB version in the reproducer. For now I just want
the information to be present, without enforcing it, but I envision
emitting a warning during replay in the future.
Differential revision: https://reviews.llvm.org/D63229
llvm-svn: 363225
This replaces the `info` typedef with a nested struct named Info. This
means we now have FooProvider and FooProvider::Info, instead of two
related but separate classes FooProvider and FooInfo. This change is
mostly cosmetic.
llvm-svn: 363211
Summary:
This is the first of a few patches I have to improve the performance of dynamic module loading on Android.
In this first diff I'll describe the context of my main motivation and will then link to it in the other diffs to avoid repeating myself.
## Motivation
I have a few scenarios where opening a specific feature on an Android app takes around 40s when lldb is attached to it. The reason for that is because 40 modules are dynamicly loaded at that point in time and each one of them is taking ~1s.
## The problem
To learn about new modules we have a breakpoint on a linker function that is called twice whenever a module is loaded. One time just before it's loaded (so lldb can check which modules are loaded) and another right after it's loaded (so lldb can check again which ones are loaded and calculate the diference).
It's figuring out which modules are loaded that is taking quite some time. This is currently done by traversing the linked list of loaded shared libraries that the linker maintains in memory. Each item in the linked list requires its own `x` packet sent to the gdb server (this is android so the network also plays a part). In my scenario there are 400+ loaded libraries and even though we read 0x800 worth of bytes at a time we still make ~180 requests that end up taking 150-200ms.
We also do this twice, once before the module is loaded (state = eAdd) and another right after (state = eConsistent) which easly adds up to ~400ms per module.
## A solution
**Implement `xfer:libraries-svr4` in lldb-server:**
I noticed in the code that loads the new modules that it had support for the `xfer:libraries-svr4` packet (added ~4 years ago to support the ds2 debug server) but we didn't support it in lldb-server. This single packet returns an xml list of all the loaded modules by the process. The advantage is that there's no more need to make 180 requests to read the linked list. Additionally this new requests takes around 10ms.
**More efficient usage of the `xfer:libraries-svr4` packet in lldb:**
When `xfer:libraries-svr4` is available the Process class has a `LoadModules` function that requests this packet and then loads or unloads modules based on the current list of loaded modules by the process.
This is the function that is used by the DYLDRendezvous class to get the list of loaded modules before and after the module is loaded. However, this is really not needed since the LoadModules function already loaded or unloaded the modules accordingly. I changed this strategy to call LoadModules only once (after the process has loaded the module).
**Bugs**
I found a few issues in lldb while implementing this and have submitted independent patches for them.
I tried to devide this into multiple logical patches to make it easier to review and discuss.
## Tests
I wanted to put these set of diffs up before having all the tests up and running to start having them reviewed from a techical point of view. I'm also having some trouble making the tests running on linux so I need more time to make that happen.
# This diff
The `xfer` packages follow the same protocol, they are requested with `xfer:<object>:<read|write>:<annex>:<offset,length>` and a return that starts with `l` or `m` depending if the offset and length covers the entire data or not. Before implementing the `xfer:libraries-svr4` I refactored the `xfer:auxv` to generically handle xfer packets so we can easly add new ones.
The overall structure of the function ends up being:
* Parse the packet into its components: object, offset etc.
* Depending on the object do its own logic to generate the data.
* Return the data based on its size, the requested offset and length.
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: mgorny, krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62499
llvm-svn: 362982
Problem discovered in the breakpoint lit test, but probably exists in others.
lldb-test splits lines on LF. Input files that are CR+LF separated (as is
common on Windows) then resulted in commands being sent to LLDB that ended
in CR, which confused the command interpreter.
This could be fixed at different levels:
1. Treat '\r' like a tab or space in the argument splitter.
2. Fix the line splitters (plural) in lldb-test.
3. Normalize the test files to LF only.
If we did only 3, I'd expect similar problems to recur, so this patch does
1 and 2. I may also do 3 in a separate patch later, but that's tricky
because I believe we have some input files that MUST use CR+LF.
Differential Revision: https://reviews.llvm.org/D62759
llvm-svn: 362844
Summary:
The `log timer dump` is showing the time of the function itself minus any function that is called from this one that also happens to be timed. However, this is really not obvious and it also makes it hard to understand the time spent in total and also which children are actually taking the time.
To get a better reading of the timer dump I added the total, children (which I named child) and also the hit count. I used these timers to figure out a performance issue and only after adding this things were more clear to me.
It looks like this:
```
(lldb) log timer dump
35.447713617 sec (total: 35.449s; child: 0.001s; count: 1374) for void SymbolFileDWARF::Index()
29.717921481 sec (total: 29.718s; child: 0.000s; count: 8230500) for const lldb_private::ConstString &lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const
21.049508865 sec (total: 24.683s; child: 3.633s; count: 1399) for void lldb_private::Symtab::InitNameIndexes()
...
```
Reviewers: clayborg, teemperor, labath, espindola, xiaobai
Reviewed By: labath, xiaobai
Subscribers: emaste, mgorny, arichardson, eraman, MaskRay, jdoerfert, labath, davide, teemperor, aprantl, erik.pilkington, jfb, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61235
llvm-svn: 361987
I touched the Broadcaster class earlier today (r361544) and noticed a
few things that could be improved. This patch includes variety of small
fixes: use early returns, use LLDB_LOG macro, use doxygen comments and
finally format the class.
llvm-svn: 361597
The copy constructor of RegularExpression doesn't initialize m_comp_err. This causes an use-of-initialized-value error when a RegularExpression is copied: the copy constructor calls Compile, which calls Free to free the existing regex if needed, which in turn reads m_comp_err to check if there's any regex to be freed.
This change calls the default constructor from the other constructors to make sure members are always initialized with sensible values. This also avoids duplicating init logic, like the RegularExpression(llvm:StringRef) constructor does, which is error prone.
Differential Revision: https://reviews.llvm.org/D62334
llvm-svn: 361546
Replaces the remaining C-style casts with explicit casts in Utility. The
motivation is that they are (1) easier to spot and (2) don't have
multiple meanings.
llvm-svn: 361458
Summary:
Log the AST of the TU associated with LLDB's `expr` command, once a declaration
is completed
Reviewers: shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62061
llvm-svn: 361362
Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this.
This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly.
Differential Revision: https://reviews.llvm.org/D61659
llvm-svn: 360292
Summary:
The DWARF spec states that the DWARF stack arguments are numbered from
the top. Our implementation of DW_OP_pick was counting them from the
bottom.
This bug probably wasn't noticed because nobody (except my upcoming
postfix-to-DWARF converter) uses DW_OP_pick, but I've cross-checked with
gdb to confirm that counting from the top is the expected behavior.
This patch fixes the implementation to match the spec and gdb behavior
and adds a test.
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D61182
llvm-svn: 359436
We recently moved API logging into the instrumentation macros. This made
that logging is now consistent and abstracted behind a macro for every
API functions, independent of the reproducers. It also means we have a
lot more output. While this is a good thing, it also meant a lot more
noise in the log, from things that aren't always equally interesting,
such as the copy constructor for example.
To improve usability, we should increase the signal-to-noise ratio. I
propose to achieve this by only logging API functions that cross the API
boundary. This is a divergence of what we had before, where a select
number of functions were logged, irregardless of the API boundary, a
concept that was introduced for the reproducers. However, I believe this
is in line with the purpose of the API log.
Differential revision: https://reviews.llvm.org/D60984
llvm-svn: 359016
Deallocating the data recorder in during the ::Keep() operation causes
problems down the line when exiting the debugger. The command
interpreter still holds a pointer to the now deallocated object and has
no way to know it no longer exists. This is exactly what the m_record
flag was meant for, although it wasn't hooked up properly either.
llvm-svn: 358916
There is an alternative method to GetConstCStringWithLength that
takes a StringRef. GetConstCStringWithLength also calls this
method in the end, so directly calling the StringRef saves
us from a unnecessary conversion to a C-string.
llvm-svn: 358357
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
For some reason I had convinced myself that functions returning by
pointer or reference do not require recording their result. However,
after further considering I don't see how that could work, at least not
with the current implementation. Interestingly enough, the reproducer
instrumentation already (mostly) accounts for this, though the
lldb-instr tool did not.
This patch adds the missing macros and updates the lldb-instr tool.
Differential revision: https://reviews.llvm.org/D60178
llvm-svn: 357639
The utility library shouldn't depend on curses, libedit or python. Move
curses to core, libedit to host and python to the python plugin.
Differential revision: https://reviews.llvm.org/D59970
llvm-svn: 357287
FindPythonInterp and FindPythonLibs do two things, they set some
variables (PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS) and update the cached
variables (PYTHON_LIBRARY, PYTHON_INCLUDE_DIR) which are also used to
specify a custom python installation.
I believe the canonical way to do this is to use the PYTHON_LIBRARIES
and PYTHON_INCLUDE_DIRS variables instead of the cached ones. However,
since the cached variables are accessible from the cache and GUI, this
is a lot less confusing when you're trying to debug why a variable did
or didn't get the value you expected. Furthermore, as far as I can tell,
the implementation uses the cached variables to set their LIBRARIES/DIRS
counterparts. This is also the reason this works today even though we
mix-and-match.
Differential revision: https://reviews.llvm.org/D59968
llvm-svn: 357282
Currently LLDB crashes when autocompleting a command that ends with a
backtick because the quote character wasn't handled. This fixes that and
adds a unit test for this function.
Differential revision: https://reviews.llvm.org/D59779
llvm-svn: 356927
The command interpreter holds a pointer to a DataRecorder. After
generating the reproducer, we deallocated all the DataRecorders, causing
the command interpreter to hold a non-null reference to an invalid
object.
This patch changes the behavior of the command provider to stop the
DataRecorders when a reproducer is generated, rather than deallocating
them.
llvm-svn: 355940
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
automatic move should not fire when returning type T in a function with
result type Expected<T>. Some compilers seem to allow that nonetheless.
llvm-svn: 355270
This patch adds the necessary logic to capture and replay commands
entered into the command interpreter. A DataRecorder shadows the input
and writes its data to a know file. During replay this file is used as
the command interpreter's input.
It's possible to the command interpreter more than once, with a
different input source. We support this scenario by using multiple
buffers. The synchronization for this takes place at the SB layer, where
we create a new recorder every time the debugger input is changed.
During replay we use the corresponding buffer as input.
Differential revision: https://reviews.llvm.org/D58564
llvm-svn: 355249
Debugging issues with instrumentation capture and replay can be
particularly tricky, especially because part of the process takes places
even before the debugger is initialized. This patch adds more logging
capabilities to these classes, hidden behind a macro define.
Differential revision: https://reviews.llvm.org/D58566
llvm-svn: 355002
Summary:
This behavior was originally added in rL252264 (git commit 76a7f365da)
in order to be extra careful with handling platforms like watchos and tvos.
However, as far as triples go, those two (and others) are treated as OSes and
not environments, so that should not really apply here.
Additionally, this behavior is incorrect and can lead to incorrect ArchSpecs.
Because android is specified as an environment and not an OS, not propogating
the environment can lead to modules and targets being misidentified.
Differential Revision: https://reviews.llvm.org/D58664
llvm-svn: 354938
Summary:
These functions should always return the opposite of the
`Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is
the same as unspecified, which is why one set of functions should give us what
we want. It's possible to have specified unknown, which is why we can't just
rely on checking the enum values of vendor/os/environment. We must also ensure
that the names of these are empty and not "unknown".
Differential Revision: https://reviews.llvm.org/D58653
llvm-svn: 354933
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
This enables the function to be called with a StringRef without jumping
through any hoops. I rename the function to "PutStringAsRawHex8" to
honor the extended interface. I also remove ".c_str()" from any calls to
this function I could find.
llvm-svn: 353841
Summary:
This adds support for auto-detection of path style to SymbolFileBreakpad
(similar to how r351328 did the same for DWARF). We guess each file
entry separately, as we have no idea which file came from which compile
units (and different compile units can have different path styles). The
breakpad generates should have already converted the paths to absolute
ones, so this guess should be reasonable accurate, but as always with
these kinds of things, it is hard to give guarantees about anything.
In an attempt to bring some unity to the path guessing logic, I move the
guessing logic from inside SymbolFileDWARF into the FileSpec class and
have both symbol files use it to implent their desired behavior.
Reviewers: clayborg, lemo, JDevlieghere
Subscribers: aprantl, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D57895
llvm-svn: 353702
GetIndexForObjectImpl generated a bunch of "conversion casts away
constness warnings". Change the function to use "const void *" (and
static_cast, while I'm at it), to avoid this.
Driver.cpp: unused variable "replay" (this was actually caused by a
subsequent partial revert of this patch). I just finish the revert by
removing the variable completely.
llvm-svn: 353405
LLDB testsuite fails when built by GCC8 on:
LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
This is because this code in LLDB codebase has undefined behavior:
#include <algorithm>
#include <string.h>
// lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731
static struct section_64 {
char sectname[16];
char segname[16];
} sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" };
int main() {
return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname));
}
It has been discussed as a (false) bugreport to GCC:
wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
https://bugzilla.redhat.com/show_bug.cgi?id=1672436
Differential Revision: https://reviews.llvm.org/D57781
llvm-svn: 353280
This patch adds the file provider which is responsible for capturing
files used by LLDB.
When capturing a reproducer, we use a file collector that is very
similar to the one used in clang. For every file that we touch, we add
an entry with a mapping from its virtual to its real path. When we
decide to generate a reproducer we copy over the files and their
permission into to reproducer folder.
When replaying a reproducer, we load the VFS mapping and instantiate a
RedirectingFileSystem. The latter will transparently use the files
available in the reproducer.
I've tested this on two macOS machines with an artificial example.
Still, it is very likely that I missed some places where we (still) use
native file system calls. I'm hoping to flesh those out while testing
with more advanced examples. However, I will fix those things in
separate patches.
Differential revision: https://reviews.llvm.org/D54617
llvm-svn: 352538
We use UUID::fromOptionalData to read UUID's from the Mach-O files, so UUID's
of all 0's are invalid UUID's.
We also get uuid's from debugserver, which need to match the file UUID's. So
we need an API that treats "000000000" as invalid as well. Added that and use it.
Differential Revision: https://reviews.llvm.org/D57195
llvm-svn: 352122
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
In the original reproducer design, I expected providers to be more
dynamic than they turned out. For example, we don't have any instances
where one provider has multiple files. Additionally, I expected there to
be less locality between capture and replay, with the provider being
defined in one place and the replay code to live in another. Both
contributed to the design of the provider info.
This patch refactors the reproducer info to be something static. This
means less magic strings and better type checking. The new design still
allows for the capture and replay code to live in different places as
long as they both have access to the new statically defined info class.
I didn't completely get rid of the index, because it is useful for (1)
sanity checking and (2) knowing what files are used by the reproducer.
Differential revision: https://reviews.llvm.org/D56814
llvm-svn: 351501
Summary:
If we opened a file which was produced on system with different path
syntax, we would parse the paths from the debug info incorrectly.
The reason for that is that we would parse the paths as they were
native. For example this meant that on linux we would treat the entire
windows path as a single file name with no directory component, and then
we would concatenate that with the single directory component from the
DW_AT_comp_dir attribute. When parsing posix paths on windows, we would
at least get the directory separators right, but we still would treat
the posix paths as relative, and concatenate them where we shouldn't.
This patch attempts to remedy this by guessing the path syntax used in
each compile unit. (Unfortunately, there is no info in DWARF which would
give the definitive path style used by the produces, so guessing is all
we can do.) Currently, this guessing is based on the DW_AT_comp_dir
attribute of the compile unit, but this can be refined later if needed
(for example, the DW_AT_name of the compile unit may also contain some
useful info). This style is then used when parsing the line table of
that compile unit.
This patch is sufficient to make the line tables come out right, and
enable breakpoint setting by file name work correctly. Setting a
breakpoint by full path still has some kinks (specifically, using a
windows-style full path will not work on linux because the path will be
parsed as a linux path), but this will require larger changes in how
breakpoint setting works.
Reviewers: clayborg, zturner, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D56543
llvm-svn: 351328
LLVM added wrappers to std::sort (r327219) that randomly shuffle the
container before sorting. The goal is to uncover non-determinism due to
undefined sorting order of objects having the same key.
This can be enabled with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON.
llvm-svn: 350679
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
Summary:
These are general purpose "utility" classes, whose functionality is not
debugger-specific in any way. As such, I believe they belong in the
Utility module.
This doesn't break any particular dependency (yet), but it reduces the
number of Core dependencies across the board.
Reviewers: zturner, jingham, teemperor, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D55361
llvm-svn: 349157
As Pavel noted on the mailing list we should only create the bottom-most
directory if it doesn't exist. This should also fix the test case on
Windows as we can use lit's temp directory.
llvm-svn: 348289
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
When I landed the initial reproducer framework I knew there were some
things that needed improvement. Rather than bundling it with a patch
that adds more functionality I split it off into this patch. I also
think the API is stable enough to add unit testing, which is included in
this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Differential revision: https://reviews.llvm.org/D54616
llvm-svn: 347716
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.
Differential revision: https://reviews.llvm.org/D54272
llvm-svn: 346598
The whole point of this change was making it possible to resolve paths
without depending on the FileSystem, which is not what I did here. Not
sure what I was thinking...
llvm-svn: 346466
In order to call real_path from the TildeExpressionResolver we need
access to the FileSystem. Since the resolver lives under utility we have
to pass in the FS.
llvm-svn: 346457
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This patch removes the ResolveExecutableLocation method from FileSpec
and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53834
llvm-svn: 345853
This patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53831
llvm-svn: 345843
This patch removes the GetByteSize method from FileSpec and updates its
uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53788
llvm-svn: 345812
This patch moves the EnumerateDirectory functionality and related enum
and typedef from FileSpec to FileSystem.
This is part of a set of patches that extracts file system related
convenience methods from FileSpec. The long term goal is to remove this
method altogether and use the iterators directly, but for introducing
the VFS into LLDB this change is sufficient.
Differential revision: https://reviews.llvm.org/D53785
llvm-svn: 345800
Only attempt to link against Backtrace if it is found. Without this,
trying to cross-compile to Windows would try to link against
"Backtrace_LIBRARY-NOTFOUND.lib".
llvm-svn: 345569
This fixes a bug PlatformDarwin::SDKSupportsModule introduced by
https://reviews.llvm.org/D47889. VersionTuple::tryParse() can deal
with an optional third (micro) component, but the parse will fail when
there are extra characters after the version number (e.g.: trying to
parse the substring "12.0.sdk" out of "iPhoneSimulator12.0.sdk" fails
after that patch). Fixed here by stripping the ".sdk" suffix first.
(Part of) rdar://problem/45041492
Differential Revision https://reviews.llvm.org/D53677
llvm-svn: 345274
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.
Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.
There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).
The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.
An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
platform -- Commands to manage and create platforms.
plugin -- Commands for managing LLDB plugins.
```
Reviewers: #lldb, jingham
Reviewed By: #lldb, jingham
Subscribers: jingham, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D51175
llvm-svn: 342181
Summary:
This patch removes the manual byte counting in all internal Stream methods.
This is now done by the automatic byte counting provided by calling `GetWrittenBytes()`
before and after writing the data (which is automatically done for us by the `ByteDelta`
utility class).
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50681
llvm-svn: 342044
This showed up in an Ubsan build of lldb (inside the CFAbsoluteTime
data formatter). As we only care about the bit pattern, we just
round to the nearest double, and truncate to a size that fits
in ulonglong_t.
<rdar://problem/44229924>
llvm-svn: 341682
code. This will enable disassembly of the optional subset of
neon that some Cortex cores support. Add a unit test to check
that a few of these instructions disassemble as expected.
<rdar://problem/26674303>
llvm-svn: 341623
Jonas Devlieghere