This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Drop SHF_LINK_ORDER flag from output.
AbandonedPublic

Authored by grimar on Sep 22 2017, 3:33 AM.

Details

Reviewers
ruiu
rafael
Summary

As was discussed in D37736 thread, we can drop SHF_LINK_ORDER
and do that early enough, so that this flag will not affect on
flags of sections that contains only symbol assignments and created in
adjustSectionsBeforeSorting().

It also looks there is no reason to keep this flag when doing final link.
this patch preserves it only when -r is given.

Diff Detail

Event Timeline

grimar created this revision.Sep 22 2017, 3:33 AM
ruiu added inline comments.Sep 22 2017, 10:59 AM
ELF/Driver.cpp
976 ↗(On Diff #116322)

This is not something I meant by "drop it early when it is processed". It just drops the flag at an arbitrary point instead of when SHF_LINK_ORDER is processed. Also, this kind of code shouldn't be in the driver.

ruiu edited edge metadata.Sep 22 2017, 11:11 AM

If you initialize LinkOrderDep based on SHF_LINK_ORDER, why don't you drop the flag when you initialize it?

In D38170#879013, @ruiu wrote:

If you initialize LinkOrderDep based on SHF_LINK_ORDER, why don't you drop the flag when you initialize it?

Not sure what you mean, I drop the flag in scanLinkOrder at line 989, exactly at the point where I initialize LinkOrderDep.

grimar added inline comments.Sep 23 2017, 9:51 AM
ELF/Driver.cpp
976 ↗(On Diff #116322)

It is processed in OutputSection::finalize() because at that place we know the order of output sections and can sort input sections in according to order flags. I could drop the flag there, but it would make this patch useless, since its aim not just to drop the flag (it is itself harmless in output I believe), but do that before we create sections in adjustSectionsBeforeSorting, so that SHF_LINK_ORDER flag do not spread on them.

I agree that the SHF_LINK_ORDER flag shouldn't need to be kept in a non-relocatable object, I kept it in I've run into at least one ELF disassembler that complained about it not being there as it was inferring that one should be there from the .ARM.exidx section name. This was many years ago and I can't remember the program though. It might be worth trying to output the exceptions with GNU readelf just to check.

The reordering of the link order sections can be moved earlier than finalize(), as soon as the order of InputSections within the OutputSections is known.

I've not got any major objections to the patch, my one minor concern is that we are treating the SHF_LINK_ORDER flag differently to all/most of the other ELF flags which could catch someone out in the future if they weren't aware of it. I'm not sure if there is a good solution for that as I don't know where a comment could be put that we could guarantee a future developer would see.

ruiu added a comment.Sep 25 2017, 7:39 PM

What I meant by "drop SHF_LINK_ORDER early" is something like this: https://reviews.llvm.org/D38269

This patch does not actually work and is not intended to be submitted, but I believe you can understand the idea.

grimar added a comment.EditedSep 26 2017, 4:39 AM
In D38170#880817, @ruiu wrote:

What I meant by "drop SHF_LINK_ORDER early" is something like this: https://reviews.llvm.org/D38269

This patch does not actually work and is not intended to be submitted, but I believe you can understand the idea.

Thanks for sample. Honestly dropping the flag in InputSection constructor was the first thing I tried. But I did not check
for Link != 0 that time I think. I remember it crashed for me when accessed null section and made me think we can not access
to other sections there because them may be not initialized yet.
So that time seems I did wrong conclusion that SHF_LINK_ORDER section was placed
earlier than its target in object from testcase that failed for me and that is why I had to add scanLinkOrder separatelly.
Indeed dropping flag in constructor looks much better.
Thanks again ! I am going to update this patch soon.

grimar updated this revision to Diff 116657.Sep 26 2017, 5:16 AM
  • Updated implementation according to review comment.
ruiu added inline comments.Sep 27 2017, 9:00 PM
ELF/InputSection.cpp
98–99
"a section with SHF_LINK_ORDER should not refer a non-regular section: " + toString(Sec)
ELF/InputSection.h
185

As always, it needs a comment.

ELF/OutputSections.cpp
447

This is O(N^2) where N is the number of input sections. Please don't do that.

grimar updated this revision to Diff 116960.Sep 28 2017, 3:28 AM
grimar marked 3 inline comments as done.
  • Addressed review comments.
ELF/InputSection.cpp
98–99

Changed in r314392 (it was legacy text).

ELF/InputSection.h
185

Done.

ELF/OutputSections.cpp
447

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.

ruiu added inline comments.Oct 1 2017, 7:24 PM
ELF/InputSection.cpp
95

Inline this function.

ELF/InputSection.h
185–187

// A value of an SHF_LINK_ORDER flag. If a section doesn't have an SHF_LINK_ORDER, it's nullptr.

ELF/OutputSections.cpp
447

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?

grimar updated this revision to Diff 117326.Oct 2 2017, 4:50 AM
grimar marked 2 inline comments as done.
  • Addressed review comments.
ELF/OutputSections.cpp
447

I do not assume it. For non-relocatable case all what I need is to know if we have
link order sections or not, so that we can sort them. In that case any value
except 0 is enough.

For -r case I believe proper behavior would be to merge together only sections that have
the same parent output sections for their link - order sections.
So link order index should be always the same.

FWIW, original code set sh_link value using first input section's value,
what does not seem correct either.

I changed code a little to make my intentions more clear, is it looks better now ?

grimar abandoned this revision.Oct 10 2017, 1:09 AM

In favor of D37736.