[RemoteInspection] Change RemoteAbsolutePointer (NFC) #82325

adrian-prantl · 2025-06-18T00:06:11Z

This patch changes RemoteAbsolutePointer to store both the symbol and the resolved address. This allows us to retire some ugly workarounds to deal with non-symbolic addresses and it fixes code paths that would need these workarounds, but haven't implemented them yet (i.e., the pack shape handling in the symbolicReferenceResolver in MetadataReader.

Addresses parts of rdar://146273066.
rdar://153687085

adrian-prantl · 2025-06-18T00:09:13Z

test with swiftlang/llvm-project#10865
@swift-ci test

include/swift/Remote/RemoteAddress.h

augusto2112 · 2025-06-18T00:20:11Z

include/swift/RemoteInspection/TypeRefBuilder.h

@@ -1871,7 +1871,7 @@ class TypeRefBuilder {
        if (auto symbol = OpaquePointerReader(
                remote::RemoteAddress(adjustedProtocolDescriptorTarget),
                PointerSize)) {
-          if (!symbol->getSymbol().empty()) {
+          if (!symbol->getSymbol().empty() && symbol->getOffset() == 0) {


Why must the offset be 0 in this case?

According to the other comments the combination of Symbol+Offset isn't actually implemented.

I just took this for granted without further investigation, but given that the Offset is never taken here, it seems plausible.

This patch changes RemoteAbsolutePointer to store both the symbol and the resolved address. This allows us to retire some ugly workarounds to deal with non-symbolic addresses and it fixes code paths that would need these workarounds, but haven't implemented them yet (i.e., the pack shape handling in the symbolicReferenceResolver in MetadatyaReader. Addresses parts of rdar://146273066. rdar://153687085

adrian-prantl · 2025-06-18T17:25:43Z

test with swiftlang/llvm-project#10865
@swift-ci test

adrian-prantl · 2025-06-18T17:26:09Z

test with swiftlang/llvm-project#10865
@swift-ci smoke test

adrian-prantl · 2025-06-18T22:14:23Z

test with swiftlang/llvm-project#10865
@swift-ci test windows

finagolfin · 2025-06-23T11:55:58Z

This pull broke a couple tests on Android x86_64 and AArch64, which I confirmed by applying this pull alone locally on Android.

Looking at both tests, they have long been disabled on linux AArch64, so maybe that's why this wasn't flagged, whereas we've been running them on Android for years without a problem until this pull.

Looking at the output for Reflection/typerefs_decoding, it is expecting this:

// CHECK: dependentMember1: A.TypesToReflect.P1.Inner
// CHECK: (dependent_member protocol=14TypesToReflect2P1P
// CHECK:   (generic_type_parameter depth=0 index=0) member=Inner)

but I see this instead:

dependentMember1:
!!! Invalid typeref: 5Inner�����Qz - Node is NULL

whereas the output from Reflection/conformance_descriptors doesn't have the listed ConformanceCheck conformances altogether anymore.

@adrian-prantl, let me know what you think.

adrian-prantl · 2025-06-24T19:26:44Z

Thanks for letting me know, I'll be taking a look.

adrian-prantl · 2025-06-24T23:20:08Z

Hmm, this one seems to actually work on linux:

PASS: Swift(linux-aarch64) :: Reflection/typeref_decoding.swift (1 of 1)

adrian-prantl · 2025-06-24T23:21:09Z

PASS: Swift(linux-aarch64) :: Reflection/conformance_descriptors.swift (2 of 2)

adrian-prantl · 2025-06-24T23:22:14Z

@finagolfin Is there a tutorial for how to set up the Android cross-compilation toolchain on Linux?

finagolfin · 2025-06-25T07:15:26Z

Hmm, maybe Android-specific then, as they pass on linux x86_64 too but fail on Android x86_64. The easiest way to check this on linux would be to download the Swift source on there as usual, get the latest LTS Android NDK 27c, make sure a prebuilt Swift host compiler is in your PATH, and build the Swift compiler and Android stdlib on there with this build-script command, before running the Reflection tests:

./swift/utils/build-script -R --android --android-ndk /path/to/android-ndk-r27c --android-arch x86_64 --android-api-level 24 --stdlib-deployment-targets=android-x86_64 -T --host-test --skip-test-linux --lit-args=--filter='Reflection/'

Unfortunately, you can't just use a prebuilt official trunk snapshot toolchain because it doesn't ship with the swift-reflection-dump utility that these tests run, but the good news is the above simple build setup is all that's required.

…82620) The tests broke on the community Android CI since #82325, and I just noticed the install issue when cross-compiling Testing with a freshly-built compiler, which I'd never done before. Also, fix the NDK path shown in the CMake output.

…wiftlang#82620) The tests broke on the community Android CI since swiftlang#82325, and I just noticed the install issue when cross-compiling Testing with a freshly-built compiler, which I'd never done before. Also, fix the NDK path shown in the CMake output.

drodriguez · 2025-07-08T20:44:03Z

FWIW, I am seeing two errors in our internal Linux builds which match the ones finagolfin reported in Android. Our Linux is not a public distro, which sometimes introduces problems, but in this case, since they were happening also in some setup, these changes might be something that might only work on the Ubuntus used for testing or something environmental:

Testing: FAIL: Swift(linux-x86_64) :: Reflection/conformance_descriptors.swift (6557 of 19897)
******************** TEST 'Swift(linux-x86_64) :: Reflection/conformance_descriptors.swift' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
... snip ...
.../swift/test/Reflection/conformance_descriptors.swift:23:15: error: CHECK-DAG: expected string not found in input
// CHECK-DAG: 16ConformanceCheck2E4O (ConformanceCheck.E4) : ConformanceCheck.P1, ConformanceCheck.P2, ConformanceCheck.P3
              ^
<stdin>:13444:14: note: scanning from here
=============
             ^

Input file: <stdin>
Check file: .../swift/test/Reflection/conformance_descriptors.swift

-dump-input=help explains the following input dump.

Input was:
<<<<<<
        .
        .
        .
    13439: (generic_type_parameter depth=0 index=0) 
    13440: (closure_binding index=0) 
    13441:  
    13442:  
    13443: CONFORMANCES: 
    13444: ============= 
dag:23                  X error: no match found
    13445: s21KeyPathComputedIDKindO (Swift.KeyPathComputedIDKind) : Swift.Hashable, Swift.Equatable 
dag:23     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    13446: s11KeyPathKindO (Swift.KeyPathKind) : Swift.Hashable, Swift.Equatable 
dag:23     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    13447: s7UnicodeO14_NFCNormalizerV5StateO (Swift.Unicode._NFCNormalizer.State) : Swift.Hashable, Swift.Equatable 
dag:23     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    13448: s7UnicodeO14_NFDNormalizerV5StateO (Swift.Unicode._NFDNormalizer.State) : Swift.Hashable, Swift.Equatable 
dag:23     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    13449: s41GetKeyPathClassAndInstanceSizeFromPatternV (Swift.GetKeyPathClassAndInstanceSizeFromPattern) : Swift.KeyPathPatternVisitor 
dag:23     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        .
        .
        .
>>>>>>

--

Testing:  0.. 10.. 20.. 30FAIL: Swift(linux-x86_64) :: Reflection/typeref_decoding.swift (6752 of 19897)
******************** TEST 'Swift(linux-x86_64) :: Reflection/typeref_decoding.swift' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
... snip ...
.../swift/test/Reflection/typeref_decoding.swift:316:11: error: CHECK: expected string not found in input
// CHECK: dependentMember1: A.TypesToReflect.P1.Inner
          ^
<stdin>:304:41: note: scanning from here
(generic_type_parameter depth=0 index=0)
                                        ^
<stdin>:383:7: note: possible intended match here
 (bound_generic_enum TypesToReflect.E1
      ^

Input file: <stdin>
Check file: .../swift/test/Reflection/typeref_decoding.swift

-dump-input=help explains the following input dump.

Input was:
<<<<<<
             .
             .
             .
           299:  (bound_generic_enum TypesToReflect.E2 
           300:  (generic_type_parameter depth=0 index=0)) 
           301:  (struct Swift.Int)) 
           302:  
           303: primaryArchetype: A 
           304: (generic_type_parameter depth=0 index=0) 
check:316'0                                             X error: no match found
           305:  
check:316'0     ~
           306: dependentMember1:  
check:316'0     ~~~~~~~~~~~~~~~~~~~
           307: !!! Invalid typeref: 5Inner����Qz - Node is NULL 
check:316'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           308: TypesToReflect.C3 
check:316'0     ~~~~~~~~~~~~~~~~~~
           309: ----------------- 
check:316'0     ~~~~~~~~~~~~~~~~~~
             .
             .
             .
           378:  (bound_generic_struct TypesToReflect.S1 
check:316'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           379:  (generic_type_parameter depth=0 index=0)) 
check:316'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           380:  (result 
check:316'0     ~~~~~~~~~
           381:  (function 
check:316'0     ~~~~~~~~~~~
           382:  (parameters 
check:316'0     ~~~~~~~~~~~~~
           383:  (bound_generic_enum TypesToReflect.E1 
check:316'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:316'1           ?                                 possible intended match
           384:  (generic_type_parameter depth=0 index=0)) 
check:316'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           385:  (result 
check:316'0     ~~~~~~~~~
           386:  (struct Swift.Int)))) 
check:316'0     ~~~~~~~~~~~~~~~~~~~~~~~
           387:  
check:316'0     ~
           388: tuple:  
check:316'0     ~~~~~~~~
             .
             .
             .
>>>>>>

--

finagolfin · 2025-07-09T11:21:10Z

Thanks for reporting, @drodriguez, are you changing the default linker to lld or doing something else unusual in your linux x86_64 testing? I find it very weird that these two tests pass on all the public linux distro CI but only fail for us: perhaps lld or something like that is the reason.

drodriguez · 2025-07-09T16:18:59Z

It might be the usage of LLD. We use LLD for ELF.

augusto2112 · 2025-07-11T00:27:27Z

I was able to reproduce this with LLD, and have a fix #82981

adrian-prantl mentioned this pull request Jun 18, 2025

[lldb] Adapt lldb to new swift::remote::RemoteAbsolutePointer interface swiftlang/llvm-project#10865

Merged

adrian-prantl requested review from kastiglione, augusto2112 and slavapestov June 18, 2025 00:08

augusto2112 approved these changes Jun 18, 2025

View reviewed changes

adrian-prantl force-pushed the 153687085 branch from ff60882 to 9381a54 Compare June 18, 2025 17:25

adrian-prantl merged commit 267d063 into swiftlang:main Jun 20, 2025
5 checks passed

finagolfin mentioned this pull request Jun 30, 2025

[android] Disable a couple Reflection tests and fix an install path #82620

Merged

finagolfin mentioned this pull request Jul 11, 2025

[RemoteMirrors] Fix losing the remote address on StaticMirror #82981

Merged

augusto2112 mentioned this pull request Jul 14, 2025

[NFC][RemoteInspection] Add an opaque AddressSpace field to RemoteAddress #82997

Merged

[RemoteInspection] Change RemoteAbsolutePointer (NFC) #82325

[RemoteInspection] Change RemoteAbsolutePointer (NFC) #82325

Uh oh!

Conversation

adrian-prantl commented Jun 18, 2025

Uh oh!

adrian-prantl commented Jun 18, 2025

Uh oh!

Uh oh!

augusto2112 Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

adrian-prantl Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

adrian-prantl Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

adrian-prantl commented Jun 18, 2025

Uh oh!

adrian-prantl commented Jun 18, 2025

Uh oh!

adrian-prantl commented Jun 18, 2025

Uh oh!

Uh oh!

finagolfin commented Jun 23, 2025

Uh oh!

adrian-prantl commented Jun 24, 2025

Uh oh!

adrian-prantl commented Jun 24, 2025

Uh oh!

adrian-prantl commented Jun 24, 2025

Uh oh!

adrian-prantl commented Jun 24, 2025

Uh oh!

finagolfin commented Jun 25, 2025

Uh oh!

drodriguez commented Jul 8, 2025

Uh oh!

finagolfin commented Jul 9, 2025

Uh oh!

drodriguez commented Jul 9, 2025

Uh oh!

augusto2112 commented Jul 11, 2025

Uh oh!

Uh oh!