[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