Commit Graph

6 Commits

Author SHA1 Message Date
Martin Storsjo c510fac569 [MinGW] Don't mark external variables as DSO local
Since MinGW supports automatically importing external variables from
DLLs even without the DLLImport attribute, we shouldn't mark them
as DSO local unless we actually know them to be local for sure.

Keep marking thread local variables as DSO local.

Differential Revision: https://reviews.llvm.org/D51382

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@340941 91177308-0d34-0410-b5e6-96231b3b80d8
2018-08-29 17:26:58 +00:00
Rafael Espindola 19347d7065 Recommit r324107 again.
The difference from the previous try is that we no longer directly
access function declarations from position independent executables. It
should work, but currently doesn't with some linkers.

It now includes a fix to not mark available_externally definitions as
dso_local.

Original message:

Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@324535 91177308-0d34-0410-b5e6-96231b3b80d8
2018-02-07 22:15:33 +00:00
Rafael Espindola 8fb574345e Revert "Recommit r324107."
This reverts commit r324500.

The bots found two failures:

    ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc
    ThreadSanitizer-x86_64 :: pie_test.cc

when using gold. The issue is a limitation in gold when building pie
binaries. I will investigate how to work around it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@324505 91177308-0d34-0410-b5e6-96231b3b80d8
2018-02-07 19:44:15 +00:00
Rafael Espindola 2f59b2a784 Recommit r324107.
It now includes a fix to not mark available_externally definitions as
dso_local.

Original message:

Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@324500 91177308-0d34-0410-b5e6-96231b3b80d8
2018-02-07 19:16:49 +00:00
Rafael Espindola 0cc8912fb2 Revert "Start setting dso_local in clang."
This reverts commit r324107.

I will have to test it on OS X.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@324108 91177308-0d34-0410-b5e6-96231b3b80d8
2018-02-02 17:29:22 +00:00
Rafael Espindola bfe30614ff Start setting dso_local in clang.
This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@324107 91177308-0d34-0410-b5e6-96231b3b80d8
2018-02-02 17:17:39 +00:00