<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 5, 2015 at 4:48 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankarke@gmail.com" target="_blank">shankarke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi All,<br><br></div>I have a design question of how your linker would be suitable for modeling ELF semantics.<br><br></div>The ELF linker needs the functionality of reading relocations ahead of symbol resolution for the following usecases :-<br><br></div>- Add linker defined symbols if there is a relocation to the symbol (Examples are : defsym, PROVIDE)<br></div></div></div></div></div></div></div></div></blockquote><div><br></div>Symbol table contains both undefined and defined symbols. We know what symbols are needed to be resolved to link that file correctly without reading relocation table.<br><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div></div>- Dont halt the linker operation if there are undefined symbols but they are not called from the root set (Do garbage collection and then report whether symbols are really undefined)<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>Dead-stripping is done after eliminating duplicate COMDAT symbols. Unreferenced symbols are naturally ignored.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div></div>- A reference to a symbol inside a group, from outside a group need to be through an undefined symbol<br></div></div></div></div></div></div></blockquote><div><br></div><div>I don't get the meaning of the question.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div></div>- For string merging, relocations are needed in advance before they can be merged.<br></div>- For identical code folding, relocations are needed in advance before they can be merged.<br></div></div></div></div></blockquote><div><br></div><div>These happen after symbol resolution and you need to read relocation table.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><br><div>There are also more usecase where there is not a symbol but a section, examples of them are :-<br><br></div><div>- sections that contain mergeable strings (.rodata)<br></div><div>- sections that contain Eh Frame information, where FDE's are discarded for functions that are garbage collected.<br></div><div><br></div>So I was trying to figure out how the Chunks and relocations would be related in the Reader, which means that it would be very similiar to what we have with the Atom model.<br><br></div>Thoughts / opinions ?<span class=""><font color="#888888"><br><br></font></span></div><span class=""><font color="#888888">Shankar Easwaran<br></font></span></div>
</blockquote></div><br></div></div>