This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - ICF: improve support of SHF_LINK_ORDER sections.
AbandonedPublic

Authored by grimar on Sep 22 2017, 9:10 AM.

Details

Reviewers
ruiu
rafael
Summary

Previously when ICF merged 2 code sections it did not take
SHF_LINK_ORDER dependencies in account at all.
So if one of order sections was absent or different from another one,
ICF still performed code folding for code sections, what was not correct.
Patch improves the support, teaching ICF to compare static contents of
SHF_LINK_ORDER sections.

Diff Detail

Event Timeline

grimar created this revision.Sep 22 2017, 9:10 AM
grimar edited the summary of this revision. (Show Details)Sep 22 2017, 9:20 AM
ruiu added inline comments.Sep 24 2017, 7:50 PM
ELF/InputSection.cpp
244

You are assuming that there's up to one dependent section, but are you sure that the assumption is correct? I don't think that's guaranteed by the standard.

grimar added inline comments.Sep 25 2017, 4:25 AM
ELF/InputSection.cpp
244

It should not be too hard to change I believe.
At the same time spec says "A typical use of this flag is to build a table that references text or data sections in address order.", it seems to me one dependency should be sufficient here, though not explicitly said. I suggest to replace the assert (in this method) checking we have only one dependent link order section with an error for now and watch.
What do you think ?

ruiu added inline comments.Sep 25 2017, 7:18 PM
ELF/InputSection.cpp
244

At least you need to be consistent with your own choice. Support multiple sections or report an error.

grimar updated this revision to Diff 116658.Sep 26 2017, 5:54 AM
  • Added error for case when multiple SHF_LINK_ORDER sections with the same target.
  • Added testcase for checking above.
ruiu added inline comments.Sep 27 2017, 8:52 PM
ELF/ICF.cpp
278

You shouldn't make this change -- you can check it on the caller side.

436–437

This is pretty odd piece of code. You do not call replace on LinkOrder section, but you are reporting that you have removed it. It looks buggy even if it is not buggy.

ELF/InputSection.cpp
244

Why don't you just add a LinkOrderSection * member to InputSection?

grimar updated this revision to Diff 116963.Sep 28 2017, 4:09 AM
grimar marked 2 inline comments as done.
  • Addressed review comments.
grimar marked an inline comment as done.Sep 28 2017, 4:09 AM
grimar added inline comments.
ELF/ICF.cpp
278

OK.

436–437

Fixed.

ELF/InputSection.cpp
244

If D38170 be landed, we will have InputSection *LinkOrderSection; in InputSectionBase, but that is different pointer.
For SHF_LINK_ORDER sections it will contain section linked to via sh_link flag. So for section X it returns section L.
This metod returns SHF_LINK_ORDER section. It is reverse, for L it returns X.

Doesn't seem we should add one more member for that, because we already have X in DependentSections member for L.
And DependentSections should be little vector normally I think, traversing is cheap.

grimar marked an inline comment as done.Oct 4 2017, 7:37 AM

Ping.

Do we want to go in this direction or should I abandon this for now ?

ruiu edited edge metadata.Nov 15 2017, 10:56 PM

If you have time to work on improving this, do you mind if I ask you to work on emitting per-function .eh_frame sections from clang?

In D38180#927065, @ruiu wrote:

If you have time to work on improving this, do you mind if I ask you to work on emitting per-function .eh_frame sections from clang?

Yes, I think at least I can try. Unfortunately I am not familar with clang code at all, so it probably will take some time before any first results,
I'll try to investigate how to implement this.

grimar abandoned this revision.Dec 1 2017, 4:12 AM