[PATCH] D68094: ELF: Don't merge SHF_LINK_ORDER sections in relocatable links.

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

At a conference right now, so I've not had a chance to test out what happens with the patch. Apologies if I've jumped to a conclusion. Assuming the .text sections that are the targets of .ARM.exidx are merged, I'm not sure that this will be sufficient for .ARM.exidx. If we are also merging the .text sections. We'll end up with:

  .text
  .ARM.exidx.text.f1 -> .text
  .ARM.exidx.text.f2 -> .text

There is no way for .ARM.exidx.text.f1 and .ARM.exidx.text.f2 to be reordered as they both have the same key (.text section address). If we happen to get unlucky, and the order of .ARM.exidx.text.f1 isn't the right one then we produce an incorrectly ordered table.

I think that there are two possible solutions given that there is an expectation that there is one .ARM.exidx section per .text section. Option 1 is to not merge sections with SHF_LINK_ORDER and not merge the sections that they have a sh_link to. This is pessimistic as on a C++ application it would pretty much disable merging on Arm as almost all .text sections have .ARM.exidx. Option 2 is to selectively merge and reorder the .ARM.exidx sections so that there is one .ARM.exidx per .text section.

  .text.f1 <- .ARM.exidx.text.f1
  .text.f2 <- .ARM.exidx.text.f2

After ld -r

  .text <- .ARM.exidx

As long as the .ARM.exidx is ordered to match the order of .text.f1 and .text.f2 in the merged .text then everything will work.

Will try to take a closer look when I get some spare time. Will be back in the office on Monday.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68094/new/

https://reviews.llvm.org/D68094