> On Sep 29, 2017, at 8:08 AM, Sam Ding <samd...@ca.ibm.com> wrote:
>
> Hi Slava & Joe,
>
> Thank you for the response.
>
> The failed test case is "generic instantiation" of KeyPath.swift. Here is
> details of log:
>
> [ RUN ] key paths.key path generic instantiation
> stdout>>> check failed at /home/wk/sw4/swift/test/stdlib/KeyPath.swift, line
> 193
> stdout>>> expected: Swift.ReferenceWritableKeyPath<a.S<Swift.Int>, Swift.Int>
> (of type Swift.ReferenceWritableKeyPath<a.S<Swift.Int>, Swift.Int>)
> stdout>>> actual: Swift.ReferenceWritableKeyPath<a.S<Swift.Int>, Swift.Int>
> (of type Swift.ReferenceWritableKeyPath<a.S<Swift.Int>, Swift.Int>)
> stdout>>> check failed at /home/wk/sw4/swift/test/stdlib/KeyPath.swift, line
> 197
> stdout>>> expected: Swift.ReferenceWritableKeyPath<a.S<Swift.String>,
> Swift.Int> (of type Swift.ReferenceWritableKeyPath<a.S<Swift.String>,
> Swift.Int>)
> stdout>>> actual: Swift.ReferenceWritableKeyPath<a.S<Swift.String>,
> Swift.Int> (of type Swift.ReferenceWritableKeyPath<a.S<Swift.String>,
> Swift.Int>)
> stdout>>> check failed at /home/wk/sw4/swift/test/stdlib/KeyPath.swift, line
> 201
> stdout>>> expected:
> Swift.ReferenceWritableKeyPath<a.S<StdlibUnittest.LifetimeTracked>,
> Swift.Int> (of type
> Swift.ReferenceWritableKeyPath<a.S<StdlibUnittest.LifetimeTracked>,
> Swift.Int>)
> stdout>>> actual:
> Swift.ReferenceWritableKeyPath<a.S<StdlibUnittest.LifetimeTracked>,
> Swift.Int> (of type
> Swift.ReferenceWritableKeyPath<a.S<StdlibUnittest.LifetimeTracked>,
> Swift.Int>)
> [ FAIL ] key paths.key path generic instantiation
>
> Other test cases of KeyPath.siwft are all passed.
> It is found that the failure reason is @stdlib/public/core/KeyPath.swift
> 85 if aComponent.header.endOfReferencePrefix
> 86 != bComponent.header.endOfReferencePrefix
> 87 || aComponent.value != bComponent.value // this is true on s390x,
> aComponent.value="struct(0)", bComponent.value="struct(48)"
> 88 || aType != bType {
> 89 return false
> 90 }
>
> Then tracing to:
> 2094 func tryToResolveOffset() {
> 2095 if header.payload ==
> RawKeyPathComponent.Header.unresolvedFieldOffsetPayload {
> 2096 // Look up offset in type metadata. The value in the pattern is the
> 2097 // offset within the metadata object.
> 2098 let metadataPtr = unsafeBitCast(base, to: UnsafeRawPointer.self)
> 2099 let offsetOfOffset = patternBuffer.pop(UInt32.self)
> 2100 print("+++++++++++ int_offsetOfOffset=\(Int(offsetOfOffset))\n")
> 2101 var offset = metadataPtr.load(fromByteOffset: Int(offsetOfOffset), //
> given the same input parameters (offsetOfOfferset=56),
> 2102 as: UInt32.self) // different "offset" (0 on s390x, and 48 on x86_64)
> 2103 // Rewrite the header for a resolved offset.
>
>
> Then it comes Builtin.loadRaw of UnsafeRawPointer.swift.gyb
>
> As My lldb and gdb do not stop @ emitBuiltinLoadRaw(),
> I inserted a "printf" in the fucntion, but it does not print out anything.
>
> Yes, I think it maybe related to alignment or endianness, so we need to find
> the source code of LoadRaw.
I think you're focusing on the wrong level of abstraction. It is extremely
unlikely that the implementation of UnsafeRawPointer.load is incorrect, because
otherwise nothing would work. You should understand UnsafeRawPointer.load as a
primitive operation, like *(uint32_t*)((char*)metadataPtr + offsetOfOffset) in
C, and look at the address that's being computed and the memory layout of the
KeyPath object being interpreted and how it differs on s390x vs. other
platforms.
-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
