This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Represent .init_array/.fini_array via synthetic sections.
AbandonedPublic

Authored by grimar on Jul 17 2017, 8:24 AM.

Details

Reviewers
ruiu
rafael
Summary

I suggest this change, it should open road for fixing PR31224.
This patch introduces InitFiniSection which holds
.init_array/.fini_array sections inside.

Idea is next: we can do the same for .ctors/.dtors in another patch.
Synthetic section for .ctors/.dtors should know how to
change sorting rules on fly depending on output section name.

Then it should be possible to mix .init_array/.ctors and .fini_array/.dtors,
like bfd/gold do easily.

Diff Detail

Event Timeline

grimar created this revision.Jul 17 2017, 8:24 AM
orivej added a subscriber: orivej.Jul 17 2017, 9:15 AM
orivej added a comment.EditedJul 17 2017, 9:27 AM

Idea is next: we can do the same for .ctors/.dtors in another patch.
Synthetic section for .ctors/.dtors should know how to change sorting rules on fly depending on output section name.

Does this allow for .ctors and .init_array to be intermixed in the output section? E.g. .ctors.1, .ctors.3, and .init_array.2 contents should be concatenated as reverse(.ctors.1) + .init_array.2 + reverse(.ctors.3).

ruiu edited edge metadata.Jul 17 2017, 11:00 AM

I don't see a reason to convert .{init,fini}_array to synthetic sections because we can basically pass through them to results. The other approach I can think of is to convert .{dtors,ctors} to .{init,fini}_array internally so that they are processed as if they were .{init,fini}_array from the beginning.

The other approach I can think of is to convert .{dtors,ctors} to .{init,fini}_array internally so that they are processed as if they were .{init,fini}_array from the beginning.

I did this in https://bugs.llvm.org/show_bug.cgi?id=31224#c22

grimar added a comment.EditedJul 18 2017, 2:09 AM

Idea is next: we can do the same for .ctors/.dtors in another patch.
Synthetic section for .ctors/.dtors should know how to change sorting rules on fly depending on output section name.

Does this allow for .ctors and .init_array to be intermixed in the output section? E.g. .ctors.1, .ctors.3, and .init_array.2 contents should be concatenated as reverse(.ctors.1) + .init_array.2 + reverse(.ctors.3).

It should be possible to implement this, but I do not think that is what bfd do when mixing them. So why LLD should ?
I think it is not what bfd do because it's built-in script is (ld.bfd -verbose):

.init_array     :
{
  PROVIDE_HIDDEN (__init_array_start = .);
  KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
  KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
  PROVIDE_HIDDEN (__init_array_end = .);
}

So it always places .init_array* first and then .ctors.* I believe.

The other approach I can think of is to convert .{dtors,ctors} to .{init,fini}_array internally so that they are processed as if they were .{init,fini}_array from the beginning.

I did this in https://bugs.llvm.org/show_bug.cgi?id=31224#c22

Probably it worth to push it on review to phab then.

It should be possible to implement this, but I do not think that is what bfd do when mixing them. So why LLD should?

I do not know how bfd interprets this script, but its test checks that they are mixed: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/testsuite/ld-elf/init-mixed.c;h=f401ded4d702be49669ecdc7893f65cc70e9fa7c;hb=HEAD
The need to mix .ctors with .init_array is the reason why gcc could not just add support for .init_array in crtbegin.o and had to change the linker.

Probably it worth to push it on review to phab then.

@ruiu has proposed another approach: https://bugs.llvm.org/show_bug.cgi?id=31224#c26, https://reviews.llvm.org/D35509

grimar abandoned this revision.Jul 24 2017, 1:42 AM

D35509 was suggested instead.