[PATCH] D18403: Access protected symbols via GOT, even in non-PIC mode
Rafael Ávila de Espíndola via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 30 07:52:54 PDT 2016
rafael added inline comments.
================
Comment at: include/llvm/IR/GlobalValue.h:371
@@ +370,3 @@
+ return !hasLocalLinkage() && !hasHiddenVisibility() &&
+ (!hasProtectedVisibility() || !(isStrongDefinitionForLinker() || hasCommonLinkage()));
+ }
----------------
The spec says:
* all of the non-default visibility attributes, when applied to a symbol reference, imply that a definition to satisfy that reference must be provided within the current executable or shared object.
So whether we have a definition or not should not change this.
I understand what you are trying to do: Given a undefined symbol, be conservative and assume it can be in another DSO. Given that we can't have copy relocs for protected, the issue is more noticeable there.
But I think that that should be handled independently. What is needed is a -mno-copy-reloc that instructs llvm to not assume that the linker can use copy relocations to fix up any bad guesses as to where a symbol is.
For example, given
```
declare void @somewhere()
define void @here() { ret void }
define void @use() {
call void @here()
call void @somewhere()
ret void
}
```
We would get:
* -relocation-model=pic:
```
callq here at PLT
callq somewhere at PLT
```
* -relocation-model=static:
```
callq here
callq somewhere
```
* -relocation-model=static -mno-copy-reloc:
```
callq here
callq somewhere at PLT
```
With a default visibility undefined symbol playing the role of a safe undefined symbol, a protected one can be required to be in this DSO as the spec says.
http://reviews.llvm.org/D18403
More information about the llvm-commits
mailing list