> On May 21, 2016, at 1:01 PM, Saleem Abdulrasool via swift-dev > <swift-dev@swift.org> wrote: > On Thu, May 19, 2016 at 12:29 PM, Joe Groff <jgr...@apple.com > <mailto:jgr...@apple.com>> wrote: > > > On May 19, 2016, at 12:22 PM, Tom Birch <fro...@gmail.com > > <mailto: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. > > 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@swift.org <mailto:swift-dev@swift.org>> wrote: > > > > > On May 18, 2016, at 6:01 PM, Saleem Abdulrasool <compn...@compnerd.org > > > <mailto:compn...@compnerd.org>> wrote: > > > > > > On Wednesday, May 18, 2016, Joe Groff <jgr...@apple.com > > > <mailto:jgr...@apple.com>> wrote: > > > > > > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev > > > > <swift-dev@swift.org <mailto: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 <mailto:swift-dev@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@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
