[PATCH] D67761: [ELF] Error if the linked-to section of a SHF_LINK_ORDER section is discarded

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D67761#1676443 <https://reviews.llvm.org/D67761#1676443>, @peter.smith wrote:

> In D67761#1675371 <https://reviews.llvm.org/D67761#1675371>, @MaskRay wrote:
>
> > >> If sh_link(a)=b && a has SHF_LINK_ORDER, we currently place a in b's dependentSections list
> > > 
> > > I need to check for tests and previous commits on this.
> >
> > If we drop the rule, we'll have to tune the SHF_LINK_ORDER rule a bit in MarkLive.cpp. As a plus(?), we'll improve compatibility with ld.bfd.
> >
> > For linkerscript/discard-section-metadata.s (4 sections formed as an rooted tree via sh_link), ld.bfd errors:
> >
> >   % ld.bfd -T a.script a -o b
> >   ld.bfd: b: sh_link of section `.bar' points to discarded section `.foo' of `a'
> >
> >
> >
>
>
> I think that LLD is being more helpful in this case. If we don't discard the dependent sections when the dependee is discarded the user is guaranteed to get an error message, effectively telling them to add another explicit discard. The only benefit I can think of for the error message is that the user might think again about discarding the section. On the whole I don't think it matters that much though as this doesn't seem to come up a lot in practice with ld.bfd. Probably due to the use of /DISCARD/ tending to be used in environments like embedded systems where metadata tends not to be used as much.


Thanks for sharing your opinion. I take this as a convenience method for users who write `/DISCARD/`: dropping a section discards all SHF_LINK_ORDER sections that link to it. Handling SHF_LINK_ORDER the same way as SHT_REL[A] seem consistent. I'll file another feature request to ld.bfd on this.

>> In the SHF_LINK_ORDER area, we seem to have some extensions that haven't been discussed with GNU developers. I am happy with the extensions but I think GNU developers should be informed.
>> 
>> 1. non-alloc SHF_LINK_ORDER  https://sourceware.org/bugzilla/show_bug.cgi?id=25021
>> 2. If A has the SHF_LINK_ORDER flag && sh_link(A)=B,   retained B implies retained A. The converse is not clear. https://sourceware.org/bugzilla/show_bug.cgi?id=24526 posted in May but no comments yet.
> 
> I think 2 is required for SHT_ARM_EXIDX sections, it looks like ld.bfd and ld.gold special case this, whereas LLD has generalised this to all SHF_LINK_ORDER sections. The ELF spec isn't particularly clear in this area so I'm comfortable with the LLD behaviour in both cases.

+1


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67761/new/

https://reviews.llvm.org/D67761