[swift-dev] Metadata Representation

[Greg Parker]

> On Sep 22, 2017, at 5:39 PM, Saleem Abdulrasool via swift-dev <swift-dev at swift.org> wrote:
> 
> Now, as it so happens, both PE and PE+ have limitations on the file size at 4GiB.  This means that we are guaranteed that the relative difference is guaranteed to fit within 32-bits. This is where things get really interesting!
> 
> We cannot generate the relocation because we are emitting the values at pointer width.  However, the value that we are emitting is a relative offset, which we just determined to be limited to 32-bits in width.  The thing is, the IMAGE_REL_AMD64_REL32 doesn't actually seem to care about the cross-setionness as you pointed out.  So, rather than emitting a pointer-width value (`.quad`), we could emit a pad (`.long 0`) and follow that with the relative displacement (`.long <expr>`).  This would be representable in the PE/COFF model.
> 
> If I understand the layout correctly, the type metadata fields are supposed to be pointer sized.  I assume that we would like to maintain that across the formats.  It may be possible to alter the emission to change the relative pointer emission to emit a pair of longs instead for PE/COFF with a 64-bit pointer value.  Basically, we cannot truncate the relocation to a IMAGE_REL_AMD64_REL32 but we could generate the appropriate relocation and pad to the desired width.
> 
> Are there any pitfalls that I should be aware of trying to adjust the emission to do this?  The only downsides that I can see is that the  emission would need to be taret dependent (that is check the output object format and the target pointer width).

Beware of sign extension.

If you have a 32-bit signed offset, and you pad it to 64 bits by prepending a 32-bit zero, the result is not a 64-bit signed offset. Negative offsets would become large positive offsets. You would also have to adjust all code that reads these offsets. Such code must read only 32 bits and sign-extend if necessary to get 64 bits.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170925/7a03acf9/attachment.html>