[swift-dev] Relative Pointers and Windows ARM

[Saleem Abdulrasool]

On Thu, May 19, 2016 at 12:29 PM, Joe Groff <jgroff at apple.com> wrote:

>
> > On May 19, 2016, at 12:22 PM, Tom Birch <froody at 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.


Would be interesting to at least see if this is possible.  Any hints on
where to get started with testing/prototyping such an approach?


>
> -Joe
>
> > cheers,
> > Tom
> >
> > On Thu, May 19, 2016 at 9:51 AM Joe Groff via swift-dev <
> swift-dev at swift.org> wrote:
> >
> > > On May 18, 2016, at 6:01 PM, Saleem Abdulrasool <compnerd at compnerd.org>
> wrote:
> > >
> > > On Wednesday, May 18, 2016, Joe Groff <jgroff at apple.com> wrote:
> > >
> > > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev <
> swift-dev at 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160521/f454aeb0/attachment.html>