[all-commits] [llvm/llvm-project] 1d3ebb: Add -f[no-]direct-access-external-data to supersed...

[Fangrui Song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 1d3ebbf537832f80be97739abc4f6962caad1dab
      https://github.com/llvm/llvm-project/commit/1d3ebbf537832f80be97739abc4f6962caad1dab
  Author: Fangrui Song <i at maskray.me>
  Date:   2021-01-09 (Sat, 09 Jan 2021)

  Changed paths:
    M clang/include/clang/Basic/CodeGenOptions.def
    M clang/include/clang/Driver/Options.td
    M clang/lib/CodeGen/CodeGenModule.cpp
    M clang/lib/Driver/ToolChains/Clang.cpp
    M clang/lib/Frontend/CompilerInvocation.cpp
    M clang/test/CodeGen/dso-local-executable.c
    A clang/test/Driver/fdirect-access-external-data.c

  Log Message:
  -----------
  Add -f[no-]direct-access-external-data to supersede -mpie-copy-relocations

GCC r218397 "x86-64: Optimize access to globals in PIE with copy reloc" made
-fpie code emit R_X86_64_PC32 to reference external data symbols by default.
Clang adopted -mpie-copy-relocations D19996 as a flexible alternative.

The name -mpie-copy-relocations can be improved [1] and does not capture the
idea that this option can apply to -fno-pic and -fpic [2], so this patch
introduces -f[no-]direct-access-external-data and makes -mpie-copy-relocations
their aliases for compatibility.

[1]
For
```
extern int var;
int get() { return var; }
```
if var is defined in another translation unit in the link unit, there is no copy
relocation.

[2]
-fno-pic -fno-direct-access-external-data is useful to avoid copy relocations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65888
If a shared object is linked with -Bsymbolic or --dynamic-list and exports a
data symbol, normally the data symbol cannot be accessed by -fno-pic code
(because by default an absolute relocation is produced which will lead to a copy
relocation). -fno-direct-access-external-data can prevent copy relocations.

-fpic -fdirect-access-external-data can avoid GOT indirection. This is like the
undefined counterpart of -fno-semantic-interposition. However, the user should
define var in another translation unit and link with -Bsymbolic or
--dynamic-list, otherwise the linker will error in a -shared link. Generally
the user has better tools for their goal but I want to mention that this
combination is valid.

On COFF, the behavior is like always -fdirect-access-external-data.
`__declspec(dllimport)` is needed to enable indirect access.

There is currently no plan to affect non-ELF behaviors or -fpic behaviors.

-fno-pic -fno-direct-access-external-data will be implemented in the subsequent patch.

GCC feature request https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112

Reviewed By: tmsriram

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


  Commit: 38a716c30f095c7d7148482070ea4a3352b926d5
      https://github.com/llvm/llvm-project/commit/38a716c30f095c7d7148482070ea4a3352b926d5
  Author: Fangrui Song <i at maskray.me>
  Date:   2021-01-09 (Sat, 09 Jan 2021)

  Changed paths:
    M clang/lib/CodeGen/CodeGenModule.cpp
    M clang/test/CodeGen/dso-local-executable.c

  Log Message:
  -----------
  Make -fno-pic respect -fno-direct-access-external-data

D92633 added -f[no-]direct-access-external-data to supersede -m[no-]pie-copy-relocations.
(The option works for -fpie but is a no-op for -fno-pic and -fpic.)

This patch makes -fno-pic -fno-direct-access-external-data drop dso_local from
global variable declarations. This usually causes the backend to emit a GOT
indirection for external data access. With a GOT relocation, the subsequent
-no-pie link will not have copy relocation even if the data symbol turns out to
be defined by a shared object.

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


Compare: https://github.com/llvm/llvm-project/compare/9724c3cff46f...38a716c30f09