[lld] r315625 - Add comment.
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 12 14:45:53 PDT 2017
Author: ruiu
Date: Thu Oct 12 14:45:53 2017
New Revision: 315625
URL: http://llvm.org/viewvc/llvm-project?rev=315625&view=rev
Log:
Add comment.
Modified:
lld/trunk/ELF/Symbols.h
Modified: lld/trunk/ELF/Symbols.h
URL: http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Symbols.h?rev=315625&r1=315624&r2=315625&view=diff
==============================================================================
--- lld/trunk/ELF/Symbols.h (original)
+++ lld/trunk/ELF/Symbols.h Thu Oct 12 14:45:53 2017
@@ -214,8 +214,23 @@ public:
const void *ElfSym, const void *Verdef)
: Defined(SymbolBody::SharedKind, Name, /*IsLocal=*/false, StOther, Type),
Verdef(Verdef), ElfSym(ElfSym) {
- // IFuncs defined in DSOs are treated as functions by the static linker.
- if (isGnuIFunc())
+ // GNU ifunc is a mechanism to allow user-supplied functions to
+ // resolve PLT slot values at load-time. This is contrary to the
+ // regualr symbol resolution scheme in which symbols are resolved just
+ // by name. Using this hook, you can program how symbols are solved
+ // for you program. For example, you can make "memcpy" to be resolved
+ // to a SSE-enabled version of memcpy only when a machine running the
+ // program supports the SSE instruction set.
+ //
+ // Naturally, such symbols should always be called through their PLT
+ // slots. What GNU ifunc symbols point to are resolver functions, and
+ // calling them directly doesn't make sense (unless you are writing a
+ // loader).
+ //
+ // For DSO symbols, we always call them through PLT slots anyway.
+ // So there's no difference between GNU ifunc and regular function
+ // symbols if they are in DSOs. So we can handle GNU_IFUCN as FUNC.
+ if (this->Type == llvm::ELF::STT_GNU_IFUNC)
this->Type = llvm::ELF::STT_FUNC;
}
More information about the llvm-commits
mailing list