<div><br><div class="gmail_quote"><div dir="auto">On Mon, Sep 18, 2017 at 9:36 AM John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>> wrote:</div><br class="m_-8048642078909164791Apple-interchange-newline"><div><div>On Sat, Sep 16, 2017 at 6:19 PM, John McCall <span><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_-8048642078909164791gmail-">> On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
> Hello,<br>
><br>
> I'd like to propose that we change the locations that we use to store the type metadata, protocol conformances, type references, reflection strings, field metadata, and associated types.<br>
><br>
> I think that it is possible to simplify the design for the linker tables by changing section names and relying on the linker to perform the work necessary to generate the tables so that they can be walked later.<br>
><br>
> Switching sections would mean that we would lose interoperability with previously built libraries. Given that there is ABI stability work going on for at least the Darwin target, I figure that this would be the best time to do this.<br>
><br>
> Would this be acceptable? Is compatibility something that we need to worry about?<br>
<br>
</span>Compatibility is not something that we're currently promising. I think this is a fine time to be working on this problem.<br>
<br>
It's not clear from your proposal whether you're just proposing changing sections or whether you're interested in more invasive changes to metadata emission. Can you be more specific.</blockquote><div><br></div><div>Certainly.</div><div><br></div><div>Right now, we have two special object files which must be included in a certain order to ensure that the sections that I mentioned earlier are bounded and grouped. However, this is unneessary. As long as the section name is a valid C identifier, the linker will group and bound the sections with special variables that it will synthesize (__{start,stop}_[SectionName]). This will allow us to replace the two file approach with a single file approach. Furthermore, it will allow the file to be injected anywhere (it drops the need for the files to appear in a specific order). Finally, it simplifies the logic so that we can write the entire thing in C rather than having to roll the begin/end content in assembly.</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Yes, if that's the case, that would be massively useful.</div><div><br></div><div>The runtime needs to be able to find these bounds in an arbitrary image, since there may be multiple images in the program containing Swift code. Are those symbols available dynamically even if it they aren't used statically?</div></div></blockquote><div dir="auto"><br></div><div dir="auto">It should be possible to preserve the symbols. In general, it is possible to dead strip symbols. So having the object that needs to be injected reference them is sufficient to ensure that they aren't dead stripped. After that, they can be dynamically looked up even if they aren't statically used.</div><div dir="auto"><br></div><div dir="auto">I'll try to get to this change soon!</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div><div style="word-wrap:break-word"><div><br></div><div>John.</div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I think that this would help reduce some of the complexity of the ELF emission. In particular, it would mean that we would change the following:</div><div><br></div><div>.swift3_typeref -> swift3_type_references<br></div><div>.swift3_reflstr -> swift3_reflection_strings</div><div>.swift3_fieldmd -> swift3_field_metadata</div><div>.swift3_assocty -> swift3_associated_types</div><div><br></div><div>.swift2_protocol_conformances -> swift2_protocol_conformances</div><div>.swift2_type_metadata -> swift2_type_metadata</div><div><br></div><div>AFAIK, ELF does not impose section name limits, so, Im not sure if there is anything to gain from the shortened names.</div><div><br></div><div>While we are changing these things around, it seems that it may be a good idea to also change the PE/COFF emission to use section grouping (as specified within the specification) so that we can have similar handling on both the ELF and COFF sides.</div><div><br></div><div>In the case of PE/COFF, the only change would be the augmentation of the grouping specifier ($B) on the existing names. The names already are within the specification limits (COFF limits section names to 8 characters). This would allow begin/end markers to be constructed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_-8048642078909164791gmail-HOEnZb"><font color="#888888"><br>
John.<br>
</font></span></blockquote></div><br>-- <br><div class="m_-8048642078909164791gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>
</div></blockquote></div><br></div></blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>