[Bug ld/26256] Support mixed SHF_LINK_ORDER & non-SHF_LINK_ORDER components in an output section

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=26256

--- Comment #13 from Fangrui Song <i at maskray dot me> ---
(In reply to H.J. Lu from comment #12)
> (In reply to Fangrui Song from comment #10)
> > (In reply to H.J. Lu from comment #8)
> > > Created attachment 13070 [details]
> > > A patch with tests
> > > 
> > > Try this.
> > 
> > With a minor change, it'll match LLD (I place ordered sections before
> > unordered sections because Solaris folks said they did so).
> > 
> > +      /* Place ordered sections before unordered sections.  */
> > +      if (bsec != NULL)
> > +   return 1;
> > +      else if (asec != NULL)
> > +   return -1;
> > +      return 0;
> > 
> > For the test case lld/test/ELF/linkorder-mixed.s , ld-new produced %t, %t1
> > and %t3 now match LLD.
> > %t2 and %t4 still don't, but they are probably corner cases and don't matter
> > in practice.
> 
> %t2 and %t4 are lld specific behavior.


I actually think %t2 and %t4 are generic: ordered .rodata.bar (.byte 3)
precedes unordered .rodata.bar (.byte 2)

  SECTIONS { .rodata : {*(.rodata.foo) *(.rodata.bar)} }

What LLD does is to perform SHF_LINK_ORDER sorting within the input section
description *(.rodata.bar). I agree that this is a corner case which can hardly
do harm in practice.

The case is somewhat similar to [SORT and multiple patterns in an input section
description](https://sourceware.org/pipermail/binutils/2020-November/114098.html).
I think the GNU ld behavior is a bit less reasonable but users probably should
not use depend on such complex behaviors anyway.


Anyway, if the patch prefers ordered sections to unordered sections, I think it
is in quite a good shape. Being divergent on %t2 and %t4 should be fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.