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.
