[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