<div dir="ltr">This idea popped up in the review thread for <a href="https://reviews.llvm.org/D25627" rel="noreferrer" style="font-size:12.8px" target="_blank">https://reviews.llvm.org/D<wbr>25627</a>.<div><br></div><div>Problem:</div><div><br></div><div>Currently, LLD creates special sections that are not just concatenations of input sections but need link-time data generation, such as .got, .plt, interp, .mips.options, etc., as output sections. We have OutputSectionBase subclasses (e.g. GotSection, PltSection, etc.) to create data. Even though this scheme works in most cases, there are a few situations that doesn't work well as you may have noticed. Here are a issues.</div><div><br></div><div> - You cannot mix special sections with other types of sections.</div><div><br></div><div>  For example, using linker scripts, you can instruct the linker put mergeable sections and non-mergeable sections into the same output section. Such script makes sense. However, LLD cannot handle such script because string merging is the special mergeable output section's feature. The output section doesn't know how to handle other types of sections, so you cannot feed non-mergeable sections to a mergeable output section.</div><div><br></div><div> - It cannot handle linker scripts like this as pointed by Eugene.</div><div><br></div><div>  .got { *(.got.plt) *(.got) }</div><div><br></div><div>   In our current architecture, .got section is an output section, so it cannot be added to other output section. There's no clean way to handle this linker script.</div><div><br></div><div>Proposal:</div><div><br></div><div>Here's my idea: how about creating all special sections as input sections instead of output sections?</div><div><br></div><div>GotSection, PltSection, etc. will be subclasses of InputSection that don't have corresponding input files. What they will do remain the same. They will be added to OutputSections just like other regular sections are added. I think we could simplify OutputSection a lot -- OutputSection will probably become a dumb container that just concatenates all input sections.</div><div><br></div><div>This approach would solve the problems described above. Now that we create .got as an special input section with ".got" as a name, so they can naturally be added to any output section. String merging occurs inside a special mergeable input section, so they can be added to any section, too.</div><div><br></div><div>So, I think by moving the implementations from OutputSection to InputSection, we can solve many problems. I do not think of any obvious problem with the approach.</div><div><br></div><div>What do you think?</div></div>