search for: stringtablesect

I would suggest converting only part of linker generated sections to input sections to reduce amount of code changes. For example it's unlikely that SymbolTableSection or StringTableSection would ever require such treatment, so why converting them to input sections? 2016-10-19 11:03 GMT+03:00 George Rimar <grimar at accesssoftek.com>: >>This idea popped up in the review thread for >> https://reviews.llvm.org/D25627. > >> >>Problem: >> >&g...

...at 10:37, Eugene Leviant via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I would suggest converting only part of linker generated sections to > > input sections to reduce amount of code changes. > > For example it's unlikely that SymbolTableSection or > > StringTableSection would ever require such treatment, so why > > converting them to input sections? > I think if the scheme works for all sections, and if it doesn't unnecessarily complicate the code, we should convert all sections to input sections in order to keep the architecture simple. "The...

This idea popped up in the review thread for https://reviews.llvm.org/D25627 . Problem: 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