[PATCH] D72197: [MC][ELF] Emit a relocation if target is defined in the same section and is non-local

Mon Jan 13 12:09:28 PST 2020

bd1976llvm added a comment.

In D72197#1806225 <https://reviews.llvm.org/D72197#1806225>, @MaskRay wrote:

> In D72197#1805438 <https://reviews.llvm.org/D72197#1805438>, @bd1976llvm wrote:
>
> > I wonder if is this really a bug or intentional. Clang and LLVM seem to ignore the possibility of symbol interposition (see: -fno-semantic-interposition). What is the LLVM policy for this?
> >
> > Also, this code is missing a case for STB_GLOBAL and visibility != STV_DEFAULT.  Actually, I have noticed before that this case is missing in various places in MC. As it stands this patch may cause a performance regression on platforms that use -fvisibility=hidden.
>
>
> Visibility is irrelevant here. For a symbol defined in the same section as the instruction, the relocation record will reference a non-SECTION symbol instead of a STT_SECTION after this change. If the symbol is STV_HIDDEN, the linker will think the symbol is non-preemptible. So, no performance regression.

For STB_GLOBAL and visibility != STV_DEFAULT symbols I don't think we need to emit a relocation record for pc-relative references within a section, no? That's what I thought the MC code did for STB_GLOBAL symbols. Unless I am mistaken, it seems that for projects that are not using -ffunction/data-sections we may be emitting many unnecessary relocation records with this patch? That is what I meant by a performance regression. However, I think that you trying to explain that this optimization isn't done and, rather than no relocation, we currently emit a relocation to the STT_SECTION symbol in the STB_GLOBAL case? If so, LGTM as long as there is a code comment added explaining why STB_LOCAL is the only case in which we consider such relocations resolvable.

> There are many ways to make a symbol non-preemptible: binding (STB_LOCAL), visibility (STV_INTERNAL, STV_PROTECTED or STV_HIDDEN), --dynamic-list, VER_NDX_LOCAL, -Bsymbolic, -Bsymbolic-functions, etc. I have made enough refactorings to lld Symbol::isPreemptible and I am confident with these things :)
> 
> GCC r212049 (first included in GCC 5) introduced -fsemantic-interposition. Yes, current Clang/LLVM behavior is like -fno-semantic-interposition. Our behavior is not ideal and @hfinkel had an RFC https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html  . This change should help -fsemantic-interposition if we decide to move towards that goal.

Thanks for clarifying the situation. I would love to see your suggested refactorings for dso_local/dso_preemptable, LinkOnceAny/LinkOnceODR, and WeakAny/WeakODR implemented. I strongly agree with these even if we are not going to support -fsemantic-interposition.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72197