[swift-dev] Builtin.loadRaw

[Joe Groff]

> On Sep 29, 2017, at 8:08 AM, Sam Ding <samding at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170929/906e9c52/attachment.html>