[swift-dev] Relative Pointers and Windows ARM

Sun May 22 16:18:10 CDT 2016

> On May 21, 2016, at 1:01 PM, Saleem Abdulrasool via swift-dev <swift-dev at swift.org> wrote:
> On Thu, May 19, 2016 at 12:29 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
> 
> > On May 19, 2016, at 12:22 PM, Tom Birch <froody at gmail.com <mailto: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?

Well, there are four places you need to worry about:
  - The parts of IRGen that emit constant relative references; these should all be using ConstantBuilder, so it should be easy to update them.
  - The parts of IRGen that emit code to dereference relative references; I'm not sure any of these actually exist right now.
  - The runtime, where like Joe says, it should be easy to abstract a template class on the runtime-traits class that's either a relative or absolute reference.
  - MetadataReader, which will need to do the right thing based on the runtime-traits class.

I think the hardest part of this is probably coming up with a pithy name. :)  It's important that callers not call something called addRelativeReference and have it just randomly add an absolute reference depending on target platform; the fact that it's sometimes relative and sometimes absolute is something that people adding new metadata features should be actively conscious of (among other things, because absolute references always have to be pointer-sized, not just 32 bits, and so the layout of the object may change).  So we should call it something that doesn't directly connote absolute vs. relative: maybe NearReference or LocalReference?

John.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160522/7775e290/attachment.html>