[WIP] Add support for capturing all possible versioned APINotes without applying them #9102
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
artemcm
force-pushed
the
SwiftAPINotesVersionedProto
branch
from
8168178 to
affd807
Compare
|
@swift-ci test |
artemcm
force-pushed
the
SwiftAPINotesVersionedProto
branch
from
affd807 to
953f903
Compare
artemcm
force-pushed
the
SwiftAPINotesVersionedProto
branch
from
953f903 to
7ee2b42
Compare
|
@swift-ci test |
|
@egorzhdan I'm working on adding tests for this, but would be curious to get your thoughts on the overall approach. |
artemcm
requested review from
MaxDesiatov and
egorzhdan
and removed request for
MaxDesiatov
|
@swift-ci test |
Introduce a debug info independent type, ImportedDeclaration, which is analogous to DWARF's DW_AT_imported_declaration, as well as a way to search them by name.
Types annotated with @_originallyDefinedIn don't live in the module listed in their mangled name. To account for this, the compiler emits a DW_TAG_imported_declaration for those types under the name of the swiftmodule these types can be found at. This patch implements the logic required to produce the mangled name that can be used in type reconstruction to successfully find these types. rdar://137146961
Introduce a debug info independent type, ImportedDeclaration, which is analogous to DWARF's DW_AT_imported_declaration, as well as a way to search them by name. (cherry picked from commit fbc0623)
…i-extension-names [ExtractAPI] reorder the module names in extension symbol graph file names
In the changed function, there is a block of debug-only ifdef'ed code that is pretty heavyweight, and it may acquire a few locks along the way. The SwiftReflectionContext itself also has its own lock. This is triggering a deadlock in some ongoing work. Reducing the scope of the reflection context allows the debug code to run without the lock acquired, and has no effect on release builds.
…ported-decl [lldb] Introduce an ImportedDeclaration and [lldb] Handle @_originallyDefinedIn [main]
Types annotated with @_originallyDefinedIn don't live in the module listed in their mangled name. To account for this, the compiler emits a DW_TAG_imported_declaration for those types under the name of the swiftmodule these types can be found at. This patch implements the logic required to produce the mangled name that can be used in type reconstruction to successfully find these types. rdar://137146961 (cherry picked from commit ce1a9d5)
…icks [🍒 swift/release/6.1] [llvm][AArch64] Fix a crash in performPostLD1Combine
The output of opt-remarks is non-deterministic because it checks the output while iterating over a DenseMap. To fix this issue, we can replace DenseMap with MapVector.
In this testcase there is an associated type for which no debug info is generated, since there is neither function nor a variable holding on to it. However, the associated type information is stored in the Witness Table, which we can query in the runtime. rdar://140940434
…120518) TestFirmwareCorefiles.py has a helper utility, create-empty-corefile.cpp, which creates corefiles with different metadata to specify the binary that should be loaded. It normally uses an actual binary's UUID for the metadata, and it uses the binary's cputype/cpusubtype for the corefile's mach header. There is one test where it creates a corefile with metadata for a UUID that cannot be found -- it is given no binary -- and in that case, the cputype/cpusubtype it sets in the core file mach header was uninitialized data. Through luck, on Darwin systems, the uninitialized data typically matched a CPU_TYPE from machine.h and the test would work. But when the value doens't match one of thoes defines, lldb would reject the corefile entirely, and the test would fail. This has been an infrequent failure on the CI bots for a while and I couldn't ever repo it. There's a recent configuration where it was happening every time and I was able to track it down. rdar://141727563 (cherry picked from commit 527595f)
**Note:** The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which will be first available in macOS 15.4. The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the ZA matrix register (SVL*SVL bytes), and the M4 supports SME2, so the ZT0 register (64 bytes). When SSVE/SME are disabled, none of these registers are provided by the kernel - reads and writes of them will fail. Unlike Linux, lldb cannot modify the SVL through a thread_set_state call, or change the processor state's SSVE/SME status. There is also no way for a process to request a lowered SVL size today, so the work that David did to handle VL/SVL changing while stepping through a process is not an issue on Darwin today. But debugserver should be providing everything necessary so we can reuse all of David's work on resizing the register contexts in lldb if it happens in the future. debugbserver sends svl, svcr, and tpidr2 in the expedited registers when a thread stops, if SSVE|SME mode are enabled (if the kernel allows it to read the ARM_SME_STATE register set). While the maximum SVL is 64 bytes on M4, the AArch64 maximum possible SVL is 256; this would give us a 64k ZA register. If debugserver sized all of its register contexts assuming the largest possible SVL, we could easily use 2MB more memory for the register contexts of all threads in a process -- and on iOS et al, processes must run within a small memory allotment and this would push us over that. Much of the work in debugserver was changing the arm64 register context from being a static compile-time array of register sets, to being initialized at runtime if debugserver is running on a machine with SME. The ZA is only created to the machine's actual maximum SVL. The size of the 32 SVE Z registers is less significant so I am statically allocating those to the architecturally largest possible SVL value today. Also, debugserver includes information about registers that share the same part of the register file. e.g. S0 and D0 are the lower parts of the NEON 128-bit V0 register. And when running on an SME machine, v0 is the lower 128 bits of the SVE Z0 register. So the register maps used when defining the VFP registers must differ depending on the capabilities of the cpu at runtime. I also changed register reading in debugserver, where formerly when debugserver was asked to read a register, and the thread_get_state read of that register failed, it would return all zero's. This is necessary when constructing a `g` packet that gets all registers - because there is no separation between register bytes, the offsets are fixed. But when we are asking for a single register (e.g. Z0) when not in SSVE/SME mode, this should return an error. This does mean that when you're running on an SME capabable machine, but not in SME mode, and do `register read -a`, lldb will report that 48 SVE registers were unavailable and 5 SME registers were unavailable. But that's only when `-a` is used. The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which is not yet in a release. The test case I wrote is skipped on current OSes. I pilfered the SME register setup from some of David's existing SME test files; there were a few Linux specific details in those tests that they weren't easy to reuse on Darwin. rdar://121608074 (cherry picked from commit 46e7823)
…ported-decl-6 [cherry-pick][lldb] Introduce an ImportedDeclaration and [lldb] Handle @_originallyDefinedIn
…ock_scope [lldb][swift] Reduce scope of a SwiftReflectionContext
…ialize-cputype-in-test-corefile-61 [lldb][Mach-O] Initialize cputype/cpusubtype in test corefiles (llvm#120518)
…m#119052) Recently I've been working on a lot of internal Python tooling, and in certain cases I want to report async to the script over DAP. Progress.h already handles this, so I've exposed Progress via the SB API so Python scripts can also update progress objects. I actually have no idea how to test this, so I just wrote a [toy command to test it](https://gist.github.com/Jlalond/48d85e75a91f7a137e3142e6a13d0947)  I also copied the first section of the extensive Progress.h class documentation to the docstrings. (cherry picked from commit 6b048ae)
As feedback on llvm#119052, it was recommended I add a new bit to delineate internal and external progress events. This patch adds this new category, and sets up Progress.h to support external events via SBProgress. (cherry picked from commit 774c226)
When testing my SBProgress DAP PR (llvm#123826), I noticed Progress update messages aren't sent over DAP. This patch adds the lldb progress event's message to the body when sent over DAP. Before  Now  Tested with my [progress tester command](https://gist.github.com/Jlalond/48d85e75a91f7a137e3142e6a13d0947), testing 10 events 5 seconds apart 1-10 (cherry picked from commit a939a9f)
…lvm#123826) Recently I added SBProgress (llvm#119052), and during that original commit I tested if the progress event was sent over LLDB-DAP, and it was. However upon the suggestion of @JDevlieghere and @labath we added an external category (llvm#120171), which I did not test. This small patch wires up DAP to listen for external events by default, and adds the external category to the SBDebugger enumeration. (cherry picked from commit b9813ce)
This is a stop-gap to prevent a very expensive operation on remote devices. This degrades the experience to what it was on the 6.0 branch, while preserving the functionality when debugging locally and on a simulator. rdar://143580031
…lvm#124233) The LiveDebugValues pass and the instruction selector (which calls salvageCopySSA) need to be consistent on what they consider a copy instruction. With llvm#75184, the definition of what a copy instruction is was narrowed for AArch64 to exclude a w->x ORR and treat it as a zero-extend rather than a copy However, to make sure LiveDebugValues still treats a w->x ORR as a copy, the new function, isCopyLikeInstr was created. We need to make sure that salvageCopySSA also calls that function. This patch addresses this mismatch. (cherry picked from commit 44c9e46)
[AArch64][WinCFI] Fix a crash due to missing seh directives
…ease/6.1-a939a9fd53d9 [🍒 swift/release/6.1] [LLDB-DAP] Send Progress update message over DAP (llvm#123837)
Disable reading conformances on remote devices.
A type alias that resolved to a type containing more type aliase can now also be handled. To safeguard against broken debug info with cyclic aliases a limit to this is also enforced. rdar://143156979
The NSError summary provider was fetching and printing the `_code` field as an unsigned integer, but it's defined to be an NSInteger, which is signed. (cherry picked from commit 7c165f7)
…ease/6.1-7c165f7fccfd [🍒 swift/release/6.1] The _code field in an NSError is signed, not unsigned. (llvm#119764)
Some clients only include LLDB.h and they won't get access to SBProgress without this. (cherry picked from commit 9d79998)
I wanted to clarify the semantics around SBProgress. Given the nature of Progress events, copying seems like the wrong idea. Making SBProgress move-only (like SBStream) seems like the better choice here. (cherry picked from commit 1f7eb6f)
[lldb] Recursively resolve type aliases when canonicalizing types
(cherry picked from commit 1af225e)
…essor. (llvm#123662) (swiftlang#9876) Attempting to collect loop guards for loops without a predecessor can lead to non-terminating recursion trying to construct a SCEV. Fixes llvm#122913. (cherry picked from commit 137d706)
Conflicts: lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.h
…able [DebugInfo][InstrRef] Treat ORRWrr as a copy instr (llvm#123102)
[InstrRef] Fix mismatch between LiveDebugValues and salvageCopySSA
artemcm
force-pushed
the
SwiftAPINotesVersionedProto
branch
from
7ee2b42 to
6d9fdaf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Leaving it up to the client to select the appropriate version to apply.