[PATCH] D38170: [ELF] - Drop SHF_LINK_ORDER flag from output.
Rui Ueyama via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Oct 1 19:24:15 PDT 2017
ruiu added inline comments.
================
Comment at: ELF/InputSection.cpp:94
+static InputSection *getLinkOrderSection(InputFile *File, uint32_t Link) {
+ InputSectionBase *Sec = File->getSections()[Link];
----------------
Inline this function.
================
Comment at: ELF/InputSection.h:185-187
+ // Sections with SHF_LINK_ORDER flag should be placed in the same relative order
+ // as sections they linked to via sh_link field. This member points to such
+ // linked section if SHF_LINK_ORDER was used.
----------------
// A value of an SHF_LINK_ORDER flag. If a section doesn't have an SHF_LINK_ORDER, it's nullptr.
================
Comment at: ELF/OutputSections.cpp:447
+static uint32_t getLinkOrder(ArrayRef<InputSection *> V) {
+ for (InputSection *IS : V)
----------------
grimar wrote:
> ruiu wrote:
> > This is O(N^2) where N is the number of input sections. Please don't do that.
> I believe that is O(Mx) here. Where M is amount of sections in output section, so that M0+M1+....+Mn == N,
> where N is total amount of input sections. Overall complexity is O(N).
> Because for each output section this function scans over its input sections once.
>
> I think you was confused by incorrect code style in `OutputSection::finalize()`, I fixed it in r314394.
>
I still do not understand this. It doesn't seem correct. You need to handle two or LinkOrderSections, right? Why can you assume that there is always up to one LinkOrderSection?
https://reviews.llvm.org/D38170
More information about the llvm-commits
mailing list