[llvm-bugs] [Bug 49780] New: Should synthetic sections be InputSections or OutputSections?

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Mar 30 17:05:57 PDT 2021


https://bugs.llvm.org/show_bug.cgi?id=49780

            Bug ID: 49780
           Summary: Should synthetic sections be InputSections or
                    OutputSections?
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: smeenai at fb.com
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com,
                    smithp352 at googlemail.com, vyng at google.com

We decided to make SyntheticSections be OutputSections back in
https://reviews.llvm.org/D77893#inline-716459. We were debating why ELF makes
them InputSections; it appears the main motivation for that design was to allow
synthetic sections to be manipulated via linker scripts, which we don't need to
support with Mach-O.

Peter Smith gave a talk on LLD's performace
(https://archive.fosdem.org/2019/schedule/event/llvm_lld/), in which he
mentioned that LLD's synthetic sections being input sections (as opposed to
output sections) significantly sped up thunks (at the 25:10 mark). Our thunk
design will likely be closer to COFF's than ELF's, so I'd be curios if this has
an effect for us.

We discussed this further in https://reviews.llvm.org/D87199#2264781, where we
decided to defer any potential refactoring until we were more feature-complete.
I don't think we're still at the point where we'd consider this refactoring
yet, but it's worth keeping in mind for the future.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210331/168aa285/attachment.html>


More information about the llvm-bugs mailing list