<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 2, 2016 at 3:15 PM, Eugene Leviant <span dir="ltr"><<a href="mailto:evgeny.leviant@gmail.com" target="_blank">evgeny.leviant@gmail.com</a>></span> wrote:<br><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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">2016-08-03 0:55 GMT+03:00 Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span>:<br><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Aug 2, 2016 at 2:45 PM, Eugene Leviant <span dir="ltr"><<a href="mailto:evgeny.leviant@gmail.com" target="_blank">evgeny.leviant@gmail.com</a>></span> wrote:<br><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"><br><br>среда, 3 августа 2016 г. пользователь Rui Ueyama  написал:<span><br><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 2, 2016 at 3:00 AM, Eugene Leviant <span dir="ltr"><<a>evgeny.leviant@gmail.com</a>></span> wrote:<br><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">evgeny777 added a comment.<br>
<br>
I think the main reason, we're using virtual input sections is that this the only way to calculate correct symbol offset. As you may know location counter is not incremented while we add input sections to output section, and the true size of input sections is known only after call to OutputSectionBase<ELFT>::assignOffsets().<br>
<br>
So if you suggest an algorithm, which can calculate correct symbol value (w/o using virtual input sections) in the case below:<br>
<br>
  .foo : { *(.foo); end_foo = .; *(.bar) }<br>
<br>
then we can probably switch to absolute symbols (BTW we can also use synthetic symbols - there is a little difference, if any).<br>
Another interesting question is what will happen if we define absolute symbol in shared object and reference it in executable? For example:<br>
<br>
  /* script for linking shared library */<br>
  SECTIONS { .text : { text_start = .; *(.text) } }<br>
<br>
So, when shared library is loaded by application, what value would text_start have, in case it is absolute? I don't know yet, but will try.<br></blockquote><div><br></div><div>At first, I suggested you use empty dummy input sections to define linker-script-defined symbols in the hope that in that way we don't need to fix symbol addresses later (I was hoping that symbol addresses are automatically fixed as attached input sections get final output addresses.) Now that we know it doesn't work for many possible use cases. Then maybe we want to eliminated dummy sections and directly define symbols as absolute (or section) symbols.</div></div></div></div></blockquote><div><br></div></span><div>Like I said, the main problem is calculating this "absolute value". How are you going to do this? Also, like George said, it is not correct to use absolute values for symbols defined inside output section description</div></blockquote><div><br></div></span><div>I think you don't need to calculate absolute values. We know the relative distance from beginning of the current output section and the current "." value, so we can create a DefinedSynthetic symbol with the output section and the relative offset.</div><span><div><br></div></span></div></div></div></blockquote></span><div>Still have to deal with thunks, changing input section size, no?</div></div></div></div></blockquote><div><br></div><div>Yes. But even with the current two-pass approach, I think the above-mentioned logic should work.</div><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></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><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>In this patch, you are trying to support assignments to symbols. However, we eventually want to support something like this, too.</div><div><br></div><div>  SECTIONS { .text : { foo.o(.text); . = ALIGN(128); bar.o(.text) } }<br></div></div></div></div></blockquote><div><br></div></span><div>I do not see any problem in doing this. I think we use the same SymbolInputSection<ELFT> but with non-zero size, so proper layout will be calculated automatically in assignOffsets. Does this make sense?</div></blockquote><div><br></div></span><div>I don't think so. Does it work for more complicated inputs, such as</div><div><br></div><div>  SECTIONS {</div><div>    .data { *(.data) }</div><div>    .text : { foo.o(.text); . += SIZEOF(.data); bar.o(.text) }  </div><span><div>  }</div><div><br></div><div>?</div></span></div></div></div></blockquote><div><br></div></span><div>I think making InputSectionBase<ELFT>::getSize() a virtual method will solve the problem, won't it?</div></div></div></div></blockquote><div><br></div><div>It makes getSize() really complicated, no? If the expression is ". = SIZEOF(.data) + ALIGN(100)", the input section need to understand the size of the output .data section as well as the current dot value. Also, no input sections have vtables now, so adding it only for getSize is probably too much.</div><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </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><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Looks like this doesn't fit to the current architecture. Currently, we create a list of input sections and assign them addresses later. But in order to process the above script, one pass would fit well. So I'm wondering if we should merge LinkerScript::createSections and LinkerScript::assignOffsets.</div></div></div></div></blockquote><div><br></div></span><div>How can this be done? We have createThunks() in between.</div></blockquote><div><br></div></span><div>Yeah, we have Thunks. I haven't thought enough about that yet. But why we can't create thunks earlier, even before createSections?</div></div></div></div></blockquote><div><br></div></span><div>Is this possible? As far as I understand thunk contains jump. which can be between two input sections (or even output sections). Until you create full layout (like we do in createSections), it looks </div><div>like a tough problem to solve.</div></div></div></div></blockquote><div><br></div><div>Well, I believe it's at least technically doable (I'm not sure how hard it is). When the Writer is called, all symbols are resolved, so all relocations should know where they point to. That means it can be determined whether they need thunks or not.</div><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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"><div><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><br>
<br>
================<br>
Comment at: ELF/LinkerScript.cpp:278<br>
@@ -176,3 +277,3 @@<br>
 // Process ONLY_IF_RO and ONLY_IF_RW.<br>
 template <class ELFT> void LinkerScript<ELFT>::filter() {<br>
   // In this loop, we remove output sections if they don't satisfy<br>
----------------<br>
</span><span>ruiu wrote:<br>
> Why did you have to make a change to this function?<br>
</span>Two main reasons:<br>
<br>
1) During filtering process some output sections may be removed. Those sections may contain symbols and SymbolInputSection object have already been created for them. To avoid crashes and/or creating dummy symbols I have to remove those virtual sections as well<br>
<br>
2) The old implementation is not technically correct, because it removes only first output section found in name lookup. We're still using OutputSectionFactory<ELFT>, so we may have several sections with the same name.<br>
<br>
Another reason (though much less significant) is that one-by-one removal from std::vector must be slow, because it stores elements on continuous region of memory.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D22683" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22683</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>
</blockquote>
</div></div></blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>