The `formatter` logs include a function name, but these functions are mostly templates
and the template type parameter is not printed, which is useful context.
This change adds a new log which is printed upon entry of `FormatManager::Get`, which
shows the formatter context as either `format`, `summary`, or `synthetic`.
Differential Revision: https://reviews.llvm.org/D154128
The `RewriteObjCClassReferences` pass was applicable only to the code generated for the
fragile ObjC ABI (v1). That ABI is no longer active (last used for i386 macOS), which
means this pass has no effect.
Sources: `OBJC_CLASS_REFERENCES_` is emitted only by `CGObjCMac`, and not by
`CGObjCNonFragileABIMac`.
Differential Revision: https://reviews.llvm.org/D153802
While looking at https://github.com/llvm/llvm-project/issues/61955
I noticed that when we send qLaunchGDBServer we check that we got a response
but not what kind of response it was.
I think this was why the bug reporter saw:
(lldb) run
error: invalid host:port specification: '[192.168.64.2]'
The missing port is because we went down a path we only should have
chosen if the operation succeeded. Since we didn't check, we went ahead
with an empty port number.
To test this I've done the following:
* Make a temporary copy of lldb-server.
* Run that as a platform.
* Remove the copy.
* Attempt to create and run a target.
This fails because the running lldb-server will try to invoke itself
and it no longer exists.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D153513
ObjectFileMachO::SetLoadAddress() should allow for a DATA segment
that has no file content to be slid in the vmaddr, it is valid
to have such a section.
Differential Revision: https://reviews.llvm.org/D154037
rdar://99744343
Adds support for a reverse DAP request to startDebugging. The new request can be used to launch child processes from lldb scripts, for example it would be start forward to configure a debug configuration for a server and a client allowing you to launch both processes with a single debug configuraiton.
Reviewed By: wallace, ivanhernandez13
Differential Revision: https://reviews.llvm.org/D153447
This reverts commit 3254623d73fb7252385817d8057640c9d5d5ffd1.
One test has been updated to add the "-s" flag which along with
86fd957af981f146a306831608d7ad2de65b9560 should fix the tests on MacOS.
An assert on hijack listener added in that patch was removed, it seems
to be correct on MacOS but not on Linux.
In two calls to ReadMemory in DWARFExpression.cpp, the buffer size
passed to ReadMemory is not actually the size of the buffer (I suspect
a copy/paste error where the variable name was not properly
updated). This caused a buffer overflow bug, which we found throuth
Address Sanitizer. This patch fixes the problem by passing the
correct buffer size to the calls to ReadMemory (and to the
DataExtractor).
Differential Revision: https://reviews.llvm.org/D153840
This commit is replacing really old LLDB code, and we've found some odd
behavior while doing this replacement. While the changes here are largely NFC,
there are some subtle changes that fix such odd behavior.
The most curious example of this is the method `FindCompleteObjCClassName`,
which has a flag `must_be_implementation`. This flag was _only_ being respected
for accelerator tables containing the atom `type_flags`, which seems
counter-intuitive. The implementation for DWARF 5 tables does not do that and
neither does the code introduced in this patch.
There were other weird cases, for example, we found boolean logic that was
always true in a code path: look for a `if !has_qualified_name...` deleted
line; that condition was true by simple if/else analysis.
Differential Revision: https://reviews.llvm.org/D153867
All the new code should match the behavior of the old exactly.
Of note, the custom queries used to be implemented inside `HashedNameToDIE.cpp`
(which is the LLDB implementation of the tables). However, when porting to LLVM,
we believe they don't belong inside the LLVM table implementation:
1. They don't require any knowledge about the table itself
2. They are not relevant for other users of these classes.
3. They use LLDB data structures.
As such, we implement these custom queries inside AppleDWARFIndex.cpp.
Types and Objective-C tables are done separately, as they have slightly
different functionality that require rewriting more code.
Differential Revision: https://reviews.llvm.org/D153866
libpanel depends on libcurses, so when linking static libraries, libpanel
should be places prior to libcurses.
This patch resolves error like:
```
.../x86_64-centos6-linux-gnu/bin/ld:
.../lib/libpanelw.a(p_show.o):
in function `show_panel':
p_show.c:(.text+0x39): undefined reference to `_nc_panelhook_sp'
.../x86_64-centos6-linux-gnu/bin/ld:
.../lib/libpanelw.a(p_show.o):
in function `update_panels_sp':
p_update.c:(.text+0x1f): undefined reference to `_nc_panelhook_sp'
collect2: error: ld returned 1 exit status
```
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D153844
While working on the broken-symlinks issue, I noticed this one place
where I was setting `find_other` to false unintentionally in the
darwin kernel platform kext/kernel scan. Small fix while I'm here.
Fix `platform process launch` on macOS where it fails for lack of auto-resuming support.
This change reproduces the resuming logic found in `Target::Launch`.
This issue was identified by @DavidSpickett in D153636. This change relies on the tests
added in that PR. Thanks David.
Differential Revision: https://reviews.llvm.org/D153922
LLDB's implementation of DWARFDataExtractor has a method that returns a
llvm::DWARFDataExtractor. In some cases, like DebugNamesDWARFIndex::Create, we
were passing an LLVM::DWARFDataExtractor to a function that expects a
LLVM:DataExtractor by value. This is causing slicing of the derived class.
While slicing is not inherently bad, it can be dangerous if the constructor of
the derived class mutates the base class in a way that leaves it in an invalid
state after slicing.
Differential Revision: https://reviews.llvm.org/D153913
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
This fixes#62068.
After 8d1de7b34af46a089eb5433c700419ad9b2923ee the following issue appeared:
```
$ ./bin/lldb /tmp/test.o
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) platform process launch -s
error: Cannot launch '': Nothing to launch
```
Previously would call target->GetRunArguments when there were no extra
arguments, so we could find out what target.run-args might be.
Once that change started relying on the first arg being the exe,
the fact that that call clears the existing argument list caused the bug.
Instead, have it set a local arg list and append that to the existing
one. Which in this case will just contain the exe name.
Since there's no existing tests for this command I've added a new file
that covers enough to check this issue.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D153636
EnumerateDirectory gets the vfs::Status of each directory entry to
decide how to process it. If it is unable to get the Status for
a directory entry, it will currently halt the directory iteration
entirely. It should only skip this entry.
Differential Revision: https://reviews.llvm.org/D153822
rdar://110861210
The shared cache has grown past the previously hardcoded limit. As a
temporary measure, I am increasing the hardcoded number of classes we
can expect to read from the shared cache. This is not a good long-term
solution.
Differential Revision: https://reviews.llvm.org/D153817
I removed ConstString from OptionValueProperties in 643ba926c1f6, but
there are a few call sites that still create a ConstString as an
argument. I did not catch these initially because ConstString has an
implicit conversion method to StringRef.
Differential Revision: https://reviews.llvm.org/D153673
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
When specifying the C-string format for dumping memory, we treat
unprintable characters as signed. Whether a character is signed or not
is implementation defined, but all printable characters are signed.
Therefore it's fair to assume that unprintable characters are unsigned.
Before this patch, "\xcf\xfa\xed\xfe\f" would be printed as
"\xffffffcf\xfffffffa\xffffffed\xfffffffe\f". Now we correctly print the
original string.
rdar://111126134
Differential revision: https://reviews.llvm.org/D153644
The use of ConstString in StructuredDataPlugin is unneccessary as fast
comparisons are not neeeded for StructuredDataPlugins.
Differential Revision: https://reviews.llvm.org/D153482
The Objective-C runtime and the shared cache has changed slightly.
Given a class_ro_t, the baseMethods ivar is now a pointer union and may
either be a method_list_t pointer or a pointer to a relative list of
lists. The entries of this relative list of lists are indexes that refer
to a specific image in the shared cache in addition to a pointer offset
to find the accompanying method_list_t. We have to go over each of these
entries, parse it, and then if the relevant image is loaded in the
process, we add those methods to the relevant clang Decl.
In order to determine if an image is loaded, the Objective-C runtime
exposes a symbol that lets us determine if a particular image is loaded.
We maintain a data structure SharedCacheImageHeaders to keep track of
that information.
There is a known issue where if an image is loaded after we create a
Decl for a class, the Decl will not have the relevant methods from that
image (i.e. for Categories).
rdar://107957209
Differential Revision: https://reviews.llvm.org/D153597
D152759 introduced the Android .zip so file support, but it only considered
POSIX path. The code also runs on Windows, so the path could be Windows path.
Support both patterns on Windows.
Differential Revision: https://reviews.llvm.org/D153390
Two new entitlements, com.apple.private.thread-set-state and
com.apple.private.set-exception-port should be included in the
debugserver entitlement plist when built internally at Apple.
The desktop builds of debugserver don't need these entitlements;
don't add them to debugserver-macosx-entitlements.plist.
rdar://108912676
rdar://103032208
This patch should address the failure of TestStackCoreScriptedProcess
that is happening specifically on x86_64.
It turns out that in 1370a1cb5b97, 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>
When LLDB needs to access a debug section, it generally calls
SectionList::FindSectionByType with the corresponding type (we have one type for
each DWARF section). However, the missing entries made some sections be
classified as "eSectionTypeOther", which makes all calls to `FindSectionByType`
fail.
With this patch, a check-lldb build with
`-DLLDB_TEST_USER_ARGS=--dwarf-version=5` reports a much lower number of
failures:
Unsupported : 327
Passed : 2423
Expectedly Failed: 16
Unresolved : 2
Failed : 52
This is down from previously 400~ failures.
Differential Revision: https://reviews.llvm.org/D153433
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
