<br><br>четверг, 28 июля 2016 г. пользователь Rui Ueyama  написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 28, 2016 at 1:22 PM, Eugene Leviant <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','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">evgeny777 added inline comments.<br>
<br>
================<br>
<span>Comment at: ELF/LinkerScript.cpp:67<br>
@@ +66,3 @@<br>
+<br>
+  // This section should never be written.<br>
+  Hdr.sh_type = SHT_NOBITS;<br>
----------------<br>
</span><span>ruiu wrote:<br>
> It's a bit misleading. This section is written, but because it is empty, there's nothing to be written in reality.<br>
</span>Not exactly. If you don't set SHT_NOBITS, lld will *attempt* to write the section and fail because file pointer is set to null.</blockquote><div><br></div><div>Well, it's philosophical question whether .bss sections are "written" to file or not. What I was trying to say is to ask you to make this comment clear as to why we are doing this. We set NOBITS because it's a dummy section just to anchor symbols that doesn't have contents.</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><br>
================<br>
Comment at: ELF/LinkerScript.cpp:179-182<br>
@@ +178,6 @@<br>
+      for (const std::unique_ptr<BaseCommand> &Base2 : Cmd->Commands)<br>
+        if (auto *Assignment = dyn_cast<SymbolAssignment>(Base2.get()))<br>
+          PendingSymbols.push_back(Assignment);<br>
+        else<br>
+          AddMultiple(Cmd->Name, cast<InputSectionDescription>(Base2.get()));<br>
+<br>
----------------<br>
</span><span>ruiu wrote:<br>
> I do not understand why you needed a concept of "pending" here. You can add a SymbolInputSection as soon as you see a new SymbolAssignment, can't you?<br>
</span>Imagine the symbol is declared before any input section rule, like in the sample below:<br>
<br>
```<br>
.foo : { begin_foo = .; *(.foo) }<br>
```<br>
<br>
Which output section will own it? You can't create output section given symbol assignment command, because you know only section name, not section attributes, which can be obtained only from InputSectionBase<ELFT>.</blockquote><div><br></div><div>This is why I think we shouldn't use Factory to create output sections in the linker script. Factory has a logic to create output sectinos in a smart way, but in the linker script, we need to create output sections just as instructed by scripts. As soon as we see SECTIONS command, we should be able to create an output section. It's related to <a href="https://reviews.llvm.org/D22749" rel="noreferrer" style="font-size:12.8px" target="_blank">https://reviews.llvm.org/D22749</a>.</div><div></div></div></div></div></blockquote><div><br></div><div>May be it's possible to just implement Factory::register(name, type, attrs), where attrs is a combination of input section attributes? I wonder what should be done if input sections are not compatible, i.e. PROGBITS/NOBITS? Raise error?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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"><div><div>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D22683" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22683</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>
</blockquote>