This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Support INSERT AFTER statement in linker script.
AbandonedPublic

Authored by grimar on Jan 24 2018, 7:32 AM.

Details

Summary

This is for PR35877.

Seems simple and isolated implementation. It remembers all sections
that are part of "INSERT AFTER" statement and makes them
to be placed like orphans. That allows orphan placing code to find
and place such sections after regular common and regular orphans.

It looks to be consistent with spec which says:
(https://sourceware.org/binutils/docs/ld/Miscellaneous-Commands.html)
"It inserts all prior linker script statements after (or before) output_section, and also
causes ‘-T’ to not override the default linker script. The exact insertion point is as for
orphan sections.".

"INSERT AFTER" sections can't refer to each other in this implementation.
(it will not place them correctly). Though that does not look what was needed in original
PR request, so should be fine probably.

Diff Detail

Event Timeline

grimar created this revision.Jan 24 2018, 7:32 AM
ruiu added a comment.Jan 30 2018, 5:12 PM

Hmm, isn't this too restricted? It may work for .text or .data because sections are sorted by section attributes, but it doesn't work for other cases, no?

In D42482#992724, @ruiu wrote:

Hmm, isn't this too restricted? It may work for .text or .data because sections are sorted by section attributes, but it doesn't work for other cases, no?

Yes, exactly. Tried to find balance between simplicity and functionality here. Original PR case was saying that such mini-scripts with "INSERT AFTER xxx"
are used in addition to default bfd script to place some sections and symbols.

If we have .text (ax) and .data (aw) and some .foo (aw) and trying to insert .foo after .text (INSERT AFTER .text).
Then .foo will be inserted after .data in our case. Though that still does not violate spec which says:
"The exact insertion point is as for orphan sections" and technically we still would insert after .text.

By "other cases", do you have some specific useful case in mind where this patch would not work ? I just wonder how much simple approach
can/should be and if we really need anything more complex than that.

grimar abandoned this revision.Feb 19 2018, 4:52 AM

As was reported on PR page it does not work good there. Going to try reimplement in a different way.