This reverts commit df054499c3.
Reverting because of build errors
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
This reverts commit 7f1028e9df.
This is because test failures
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropriate to directly access the GDBRemoteCommunication there. And
dumping whatever history the process plugin has collected during the run isn't
gdb-remote specific...
Differential Revision: https://reviews.llvm.org/D154992
These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we always feed it with a valid
pointer. It would therefore make more sense to have this take a
reference.
Differential Revision: https://reviews.llvm.org/D154883
`Instruction::TestEmulation` takes a `Stream *` and checks it for validity.
However, this is unnecessary as we can always ensure that we never pass
`nullptr` for the `Stream` argument. The only use of
`Instruction::TestEmulation` currently is `SBInstruction::TestEmulation`
which gets the `Stream` from an `SBStream`, and `SBStream::ref` can
return a `Stream &` guaranteed.
Differential Revision: https://reviews.llvm.org/D154757
We always assume these streams are valid, might as well take references
instead of raw pointers.
Differential Revision: https://reviews.llvm.org/D154549
Also, make it possible for new Targets which haven't been added to
the TargetList yet to check for interruption, and add a few more
places in building modules where we can check for interruption.
Differential Revision: https://reviews.llvm.org/D154542
This does 2 things:
- Corrects a minor typo (`value subvalue` -> `valid subvalue`)
- Removes an unnecessary instance of `str().c_str()` (creating a
temporary std::string from a StringRef just to get a valid
null-terminated string).
Differential Revision: https://reviews.llvm.org/D154387
This method, as far as I can ascertain, is non-trivial to actually use
to work with (if not impossible). It doesn't make sense to use from
Python and you do not have access to the accompanying TypeSystem, so it
doesn't really do anything useful.
A possible follow-up is to gut the implementation and have it return `nullptr`.
Differential Revision: https://reviews.llvm.org/D153918
For some context, Raphael tried to this before: https://reviews.llvm.org/D104231
These methods are not tested at all, and in some cases, are not even fully
implemented (e.g. SBHostOS::ThreadCreated). I'm not convinced it's
possible to use these correctly from Python, and I'm not aware of any
users of these methods. It's difficult to remove these methods
wholesale, but we can start with deprecating them.
A possible follow-up to this change (which may require an RFC to get
more buy in from the community) is to gut these functions entirely. That
is, remove the implementations and replace them either with nothing or
have them dump out a message to stderr saying not to use these.
Differential Revision: https://reviews.llvm.org/D153900
We recently saw an uptick in internal reports complaining that LLDB is
slow when sources on network file systems are inaccessible. I looked at
the SourceManger and its cache and I think there’s some room for
improvement in terms of reducing file system accesses:
1. We always resolve the path.
2. We always check the timestamp.
3. We always recheck the file system for negative cache hits.
D153726 fixes (1) but (2) and (3) are necessary because of the cache’s
current design. Source files are cached at the debugger level which
means that the source file cache can span multiple targets and
processes. It wouldn't be correct to not reload a modified or new file
from disk.
We can however significantly reduce the number of file system accesses
by using a two level cache design: one cache at the debugger level and
one at the process level:
- The cache at the debugger level works the way it does today. There is
no negative cache: if we can't find the file on disk, we'll try again
next time the cache is queried. If a cached file's timestamp changes
or if its path remapping changes, the cached file is evicted and we
reload it from disk.
- The cache at the process level is design to avoid accessing the file
system. It doesn't check the file's modification time. It caches
negative results, so if a file didn't exist, it doesn't try to reread
it from disk. Checking if the path remapping changed is cheap
(doesn't involve checking the file system) and is the only way for a
file to get evicted from the process cache.
The result of this patch is that LLDB will not show you new content if a
file is modified or created while a process is running. I would argue
that this is what most people would expect, but it is a change from how
LLDB behaves today.
For an average stop, we query the source cache 4 times. With the current
implementation, that's 4 stats to get the modification time, If the file
doesn't exist on disk, that's an additional 4 stats. Before D153726, if
the path starts with a ~ there are another additional 4 calls to
realpath. When debugging sources on a slow (network) file system, this
quickly adds up.
In addition to the two level caching, this patch also adds a source
logging channel and synchronization to the source file cache. The
logging was helpful during development and hopefully will help us triage
issues in the future. The synchronization isn't a new requirement: as
the cache is shared across targets, there is no guarantees that it can't
be accessed concurrently. The patch also fixes a bug where we would only
set the source remapping ID if the un-remapped file didn't exist, which
led to the file getting evicted from the cache on every access.
rdar://110787562
Differential revision: https://reviews.llvm.org/D153834
We already have LLDB_DEPRECATED which is used to mark methods as
deprecated with a message and an alternative to use instead. This is
expresses an intent of "We recognize this functionality is useful but
there are some pitfalls with the interface we have exposed."
In other cases, there are no "alternative" methods to use and the code should be
refactored to avoid using a method entirely. For example,
`SBValue::Cast` should be avoided in favor of using the expression
evaluator to perform a cast. There isn't a mechanical solution, the
recommendation is to instead refactor your code.
This commit renames the existing `LLDB_DEPRECATED` to
`LLDB_DEPRECATED_FIXME`, and adds a `LLDB_DEPRECATED` macro to cover the
second scenario.
Differential Revision: https://reviews.llvm.org/D153928
Instead of just returning a raw `const char *`, I think llvm::StringRef
would make more sense. Most of the time that we use the return value of
`GetProcessPluginName` we're passing it to `CreateProcess` which takes a
StringRef anyway.
Differential Revision: https://reviews.llvm.org/D153825
A very old commit (9422dd64f8) changed the signature of this function in a
number of ways. This patch aims to improve it:
1. Reword the documentation, which still mentions old parameters that no longer
exist, and to elaborate upon the behavior of this function.
2. Remove the unnecessary parameter `op_addr_idx`. This parameter is odd in a
couple of ways: we never use it with a value that is non-zero, and the matching
`Update_DW_OP_addr` function doesn't use a similar parameter. We also document
that this new behavior. If we ever decide to handle multiple "DW_OP_addr", we
can introduce the complexity again.
Differential Revision: https://reviews.llvm.org/D154265
Currently, source files are cached by their resolved path. This means
that before we can query the cache, we potentially have to resolve the
path, which can be slow. This patch avoids the call to FileSystem::Resolve
by caching both the resolved and unresolved path. We now only resolve
the path once when we create and cache a new file.
rdar://110787562
Differential revision: https://reviews.llvm.org/D153726
Now that we have a proper way to deprecate things in the SB API, we
should apply it where we have manually done so with comments.
Differential Revision: https://reviews.llvm.org/D153824
The underlying structures no longer use ConstString so we can remove it
wholesale from PluginManager now.
Differential Revision: https://reviews.llvm.org/D153818
Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we support is Arm's scalable vectors (SVE) which can be up to 256 bytes long.
This means for most operations aside from SVE, we're wasting 192 bytes
of it. Which is ok given that we don't have to pay the cost of a heap
alocation and 256 bytes isn't all that much overall.
With the introduction of the Arm Scalable Matrix extension there is a new
array storage register, ZA. This register is essentially a square made up of
SVE vectors. Therefore ZA could be up to 64kb in size.
https://developer.arm.com/documentation/ddi0616/latest/
"The Effective Streaming SVE vector length, SVL, is a power of two in the range 128 to 2048 bits inclusive."
"The ZA storage is architectural register state consisting of a two-dimensional ZA array of [SVLB × SVLB] bytes."
99% of operations will never touch ZA and making every stack frame 64kb+ just
for that slim chance is a bad idea.
Instead I'm switching register handling to use SmallVector with a stack allocation
size of kTypicalRegisterByteSize. kMaxRegisterByteSize will be used in places
where we can't predict the size of register we're reading (in the GDB remote client).
The result is that the 99% of small register operations can use the stack
as before and the actual ZA operations will move to the heap as needed.
I tested this by first working out -wframe-larger-than values for all the
libraries using the arrays previously. With this change I was able to increase
kMaxRegisterByteSize to 256*256 without hitting those limits. With the
exception of the GDB server which needs to use a max size buffer.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D153626
Add two new source subcommands: source cache dump and source cache
clear. As the name implies the first one dumps the source cache while
the later clears the cache.
This patch was motivated by a handful of (internal) bug reports related
to sources not being available. Right now those issues can be hard to
diagnose. The new commands give users, as well as us as developers, more
insight into and control over the source cache.
Differential revision: https://reviews.llvm.org/D153685
The use of ConstString in StructuredDataPlugin is unneccessary as fast
comparisons are not neeeded for StructuredDataPlugins.
Differential Revision: https://reviews.llvm.org/D153482
This patch should address the failure of TestStackCoreScriptedProcess
that is happening specifically on x86_64.
It turns out that in 1370a1cb5b, I changed the way we extract integers
from a `StructuredData::Dictionary` and in order to get a stop info from
the scripted process, we call a method that returns a `SBStructuredData`
containing the stop reason data.
TestStackCoreScriptedProcess` was failing specifically on x86_64 because
the stop info dictionary contains the signal number, that the `Scripted
Thread` was trying to extract as a signed integer where it was actually
parsed as an unsigned integer. That caused `GetValueForKeyAsInteger` to
return the default value parameter, `LLDB_INVALID_SIGNAL_NUMBER`.
This patch address the issue by extracting the signal number with the
appropriate type and re-enables the test.
Differential Revision: https://reviews.llvm.org/D152848
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This teaches DumpRegisterInfo to generate a table from the register
flags type. It just calls a method on RegisterFlags.
As such, the extra tests are minimal and only show that the intergration
works. Exhaustive formatting tests are done with RegisterFlags itself.
Example:
```
(lldb) register info cpsr
Name: cpsr
Size: 4 bytes (32 bits)
In sets: general (index 0)
| 31 | 30 | 29 | 28 | 27-26 | 25 | 24 | 23 | 22 | 21 | 20 | 19-13 | 12 | 11-10 | 9 | 8 | 7 | 6 | 5 | 4 | 3-2 | 1 | 0 |
|----|----|----|----|-------|-----|-----|-----|-----|----|----|-------|------|-------|---|---|---|---|---|-----|-----|---|----|
| N | Z | C | V | | TCO | DIT | UAO | PAN | SS | IL | | SSBS | | D | A | I | F | | nRW | EL | | SP |
```
LLDB limits the max terminal width to 80 chars by default.
So to get that full width output you will need to change the "term-width"
setting to something higher.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D152918
This will be used by the "register info" command to show
the layout of register contents. For example if we have
these fields coming in from XML:
```
<field name="D" start="0" end="7"/>
<field name="C" start="8" end="15"/>
<field name="B" start="16" end="23"/>
<field name="A" start="24" end="31"/>
```
We get:
```
| 31-24 | 23-16 | 15-8 | 7-0 |
|-------|-------|------|-----|
| A | B | C | D |
```
Note that this is only the layout, not the values.
For values, use "register read".
The tables' columns are center padded (left bias
if there's an odd padding) and will wrap if the terminal width
is too low.
```
| 31-24 | 23-16 |
|-------|-------|
| A | B |
| 15-8 | 7-0 |
|------|-----|
| C | D |
```
This means we match the horizontal format seen in many architecture
manuals but don't spam the user with lots of misaligned text when the
output gets very long.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D152917
This adds a new command that will show all the information lldb
knows about a register.
```
(lldb) register info s0
Name: s0
Size: 4 bytes (32 bits)
Invalidates: v0, d0
Read from: v0
In sets: Floating Point Registers (index 1)
```
Currently it only allows a single register, and we get the
information from the RegisterInfo structure.
For those of us who know the architecture well, this information
is all pretty obvious. For those who don't, it's nice to have it
at a glance without leaving the debugger.
I hope to have more in depth information to show here in the future,
which will be of wider use.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D152916
In Android API level 23 and above, dynamic loader is able to load .so file
directly from APK, which is zip file.
https://android.googlesource.com/platform/bionic/+/master/
android-changes-for-ndk-developers.md#
opening-shared-libraries-directly-from-an-apk
The .so file is page aligned and uncompressed, so
ObjectFileELF::GetModuleSpecifications works with .so file offset and size
directly from zip file without extracting it. (D152757)
GDBRemoteCommunicationServerCommon::GetModuleInfo returns a module spec to LLDB
with "zip_path!/so_path" file spec, which is passed through from Android
dynamic loader, and the .so file offset and size.
PlatformAndroid::DownloadModuleSlice uses 'shell dd' to download the .so file
slice from the zip file with the .so file offset and size.
Differential Revision: https://reviews.llvm.org/D152759
Remove `virtual` from `ValueObject` functions that aren't overridden.
One such function, `IsArrayItemForPointer`, is not called and so is instead deleted.
Differential Revision: https://reviews.llvm.org/D153088
Have the Progress class spawn a thread to periodically send progress
reports.
The reporting period could be made configurable, but for now I've
hardcoded it to 100ms. (This is the main WIP part)
It could be argued that creating a thread for progress reporting adds
overhead, but I would counter that by saying "If the task is so fast
that creating a thread noticably slows it down, then it really doesn't
need progress reporting".
For me, this speeds up DWARF indexing by about 1.5% (which is only
slightly above the error bars), but I expect it will have a much bigger
impact in situations where printing a single progress update takes a
nontrivial amount of time.
Differential Revision: https://reviews.llvm.org/D152364
To aid in integration testing/debugging. Verifying that the address
mask/addressable bits values from different sources are correctly
registered by lldb.
None of these need to be in the ConstString StringPool. For the most
part they are constant strings and do not require fast comparisons.
I did change IOHandlerDelegateMultiline slightly -- specifically, the
`m_end_line` member always has a `\n` at the end of it now. This was so
that `IOHandlerGetControlSequence` can always return a StringRef. This
did require a slight change to `IOHandlerIsInputComplete` where we must
drop the newline before comparing it against the input parameter.
Differential Revision: https://reviews.llvm.org/D151597
lldb-server for Android does not build with NDK r21 and above due to
RetryAfterSignal and Bionic ::open mismatch.
https://github.com/llvm/llvm-project/issues/54727
Apply the LLVM patch to LLDB.
0a0e411204
> In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing
> compile errors of RetryAfterSignal due to overload resolution. Wrapping
> the call in a lambda avoids this.
Differential Revision: https://reviews.llvm.org/D152712
I want to add some error handling to DynamicRegisterInfo because there
are many operations that can fail and many of these operations do not
give meaningful information back to the caller.
To begin that process, I want to add a static method that is responsible
for creating a DynamicRegisterInfo from a StructuredData::Dictionary
(and ArchSpec). This is meant to replace the equivalent constructor
because constructors are ill-equipped to perform error handling.
Differential Revision: https://reviews.llvm.org/D152594
