[PATCH] D35487: [ELF] - Represent .init_array/.fini_array via synthetic sections.

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In https://reviews.llvm.org/D35487#811503, @orivej wrote:

> > 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 is built-in script is (ld.bfd -versbose):

  .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.

In https://reviews.llvm.org/D35487#811659, @orivej wrote:

> > 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.


https://reviews.llvm.org/D35487