> On May 19, 2016, at 12:22 PM, Tom Birch <fro...@gmail.com> wrote:
>
> Would it be acceptable to make relative pointers optional, so we can pay the
> extra load-time cost on platforms where it's hard/undesirable to implement
> them?
That's also a reasonable answer, since sliding DLLs is already fairly costly.
We'd need a bunch of extra tests to ensure both the relative and absolute forms
work, though maybe with David Farler's work to abstract relative addresses it's
already straightforward to have the RelativePointer<..> templates in the
runtime work in a platform-independent way.
-Joe
> cheers,
> Tom
>
> On Thu, May 19, 2016 at 9:51 AM Joe Groff via swift-dev <swift-dev@swift.org>
> wrote:
>
> > On May 18, 2016, at 6:01 PM, Saleem Abdulrasool <compn...@compnerd.org>
> > wrote:
> >
> > On Wednesday, May 18, 2016, Joe Groff <jgr...@apple.com> wrote:
> >
> > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev
> > > <swift-dev@swift.org> wrote:
> > >
> > > Hi,
> > >
> > > It seems that there are assumptions about the ability to create relative
> > > address across sections which doesn't seem possible on Windows ARM.
> > >
> > > Consider the following swift code:
> > >
> > > final class _ContiguousArrayStorage<Element> { }
> > >
> > > When compiled for Windows x86 (via swiftc -c -target i686-windows
> > > -parse-as-library -parse-stdlib -module-name Swift -o Swift.obj
> > > reduced.swift) it will generate the metadata pattern as:
> > >
> > > __TMPCs23_ContiguousArrayStorage:
> > > ...
> > > .long
> > > __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)
> > > ...
> > >
> > > This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit
> > > relative displacement of the target.
> > >
> > > On Windows ARM (swiftc -c -target i686-windows -parse-pas-library
> > > -parse-stdlib -module-name Swift -o Swift.obj reduced.swift) it will
> > > generate similar assembly:
> > >
> > > _TMPCs23_ContiguousArrayStorage:
> > > ...
> > > .long
> > > _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)
> > > ...
> > >
> > > However, this generates an IMAGE_REL_ARM_ADDR32 relocation which is the
> > > 32-bit VA of the target. If the symbol are in the same section, it is
> > > possible to get a relative value. However, I don't really see a way to
> > > generate a relative offset across sections. There is no relocation in
> > > the COFF ARM specification which provides the 32-bit relative
> > > displacement of the target. There are 20, 23, and 24 bit relative
> > > displacements designed specifically for branch instructions, but none
> > > that would operate on generic data.
> > >
> > > Is there a good way to address this ABI issue? Or perhaps do we need
> > > something more invasive to support such targets? Now, I might be
> > > completely overlooking something simple that I didn't consider, so
> > > pointing that out would be greatly appreciated as well.
> >
> > That's unfortunate. One possibly-crazy solution would be to use a different
> > object format that does support the necessary relocations, such as LLVM's
> > win32-macho target. That would forgo interoperability with non-LLVM
> > toolchains, of course
> >
> > Yeah, it would make interoperability harder. But, is there a loader for
> > macho on Windows?
>
> Sorry, if it wasn't clear, I meant that you could use mach-o (or ELF, or any
> object format really) for .o and .a files. You'd still link them into PE
> executables and DLLs.
>
> -Joe
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
