[PATCH] D22683: [ELF] Symbol assignment within input section list

[Eugene Leviant via llvm-commits]

evgeny777 added a comment.

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().

So if you suggest an algorithm, which can calculate correct symbol value (w/o using virtual input sections) in the case below:

  .foo : { *(.foo); end_foo = .; *(.bar) }

then we can probably switch to absolute symbols (BTW we can also use synthetic symbols - there is a little difference, if any). 
Another interesting question is what will happen if we define absolute symbol in shared object and reference it in executable? For example:

  /* script for linking shared library */
  SECTIONS { .text : { text_start = .; *(.text) } }

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.


================
Comment at: ELF/LinkerScript.cpp:278
@@ -176,3 +277,3 @@
 // Process ONLY_IF_RO and ONLY_IF_RW.
 template <class ELFT> void LinkerScript<ELFT>::filter() {
   // In this loop, we remove output sections if they don't satisfy
----------------
ruiu wrote:
> Why did you have to make a change to this function?
Two main reasons:

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

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.

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.


https://reviews.llvm.org/D22683