[Bug c/100483] New: Extend -fno-semantic-interposition to global variables

[Bug c/100483] New: Extend -fno-semantic-interposition to global variables

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

            Bug ID: 100483
           Summary: Extend -fno-semantic-interposition to global variables
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: i at maskray dot me
  Target Milestone: ---

% cat a.c
int var;
int foo() { return var; }


(I implemented this for clang 11 x86)
% clang -fpic -fno-semantic-interposition -O2 -S a.c
% cat a.s
...
foo:                                    # @foo
.Lfoo$local:
# %bb.0:                                # %entry
        movl    .Lvar$local(%rip), %eax
        retq
...
var:
.Lvar$local:
        .long   0                               # 0x0
        .size   var, 4


# On x86-64, because of R_X86_64_REX_GOTPCRELX, it isn't too bad without the
optimization.
# This is more useful on other architectures without GOT optimization.
# With my clang patch https://reviews.llvm.org/D101873
% clang -target aarch64 -fpic -fno-semantic-interposition
-fno-asynchronous-unwind-tables -O2 -S a.c
% cat a.s
...
foo:                                    // @foo
.Lfoo$local:
// %bb.0:                               // %entry
        adrp    x8, .Lvar$local
        ldr     w0, [x8, :lo12:.Lvar$local]
        ret

[Bug c/100483] Extend -fno-semantic-interposition to global variables

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

--- Comment #1 from Fangrui Song <i at maskray dot me> ---
Another request is a new option: -fno-semantic-interposition-function. With
this option, we only assume functions cannot be interposed.
-fno-semantic-interposition assumes both functions and variables cannot be
interposed.

[Bug c/100483] Extend -fno-semantic-interposition to global variables

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
I'm afraid this is potentially misunderstanding what the word 'semantic' in
-fno-semantic-interposition implies. I am not the author, but I always
understood this like so:

GCC is concerned with two aspects of ELF interposition: address interposition
(for address uniqueness) and functionality interposition (e.g. hooking malloc).
For optimization, the compiler cares a lot about the latter (it blocks inlining
and other optimizations), but not so much about the former (taking an address
of a global is rarely on the hot paths, so it's not critical to convert GOT
loads to pc-relative relocations).

So GCC splits ELF interposition concerns to 'address interposition' and
'semantic interposition', maintains the ability to perform the former (so
address uniqueness is not broken), and allows the programmer to promise that
semantic interposition (interposing a function with another function that acts
differently) does not happen.

To illustrate, compiling

void f(){
  asm("#");
}
void *g(){
  f();
  return f;
}

with -O2 -fpic -fno-semantic-interposition yields

f:
        #
        ret
g:
        #
        movq    f@GOTPCREL(%rip), %rax
        ret

i.e. the call is inlined, but taking the address goes through the GOT.

[Bug c/100483] Extend -fno-semantic-interposition to global variables

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
As author of the flag I agree with Alexander.

-fno-semantic-interposition basically means that variables or functions can be
interposed only if the replacement is semantically equivalent. For variables it
means that they have same constructor and for function that the effect of the
function call is the same. So it allows inter-procedural optimization across
interposable functions and constant folding of reads of constant interposable
variables.

% cat a.c
int var;
int foo() { return var; }


(I implemented this for clang 11 x86)
% clang -fpic -fno-semantic-interposition -O2 -S a.c
% cat a.s
...
foo:                                    # @foo
.Lfoo$local:
# %bb.0:                                # %entry
        movl    .Lvar$local(%rip), %eax
        retq
...

this is wrong transformation since it will break when one writes var in one DSO
and reads it from another.

I think it is misinterpretation of semantic interposition flag at clang's side.

[Bug c/100483] Extend -fno-semantic-interposition to global variables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Symbol resolution in an executable or a shared library at run-time is
determined by

1. Linker options + all input files at link-time.
2. ld.so + all shared libraries at run-time.

Add a compiler option at compile-time has very limited impact on symbol
resolution at run-time.

My GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION proposal provides a way
to specify symbol resolution at compile-time, link-time and
link-time.

[Bug c/100483] Extend -fno-semantic-interposition to global variables

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Fangrui Song <i at maskray dot me> ---
(In reply to Jan Hubicka from comment #3)

Thanks for the clarification. I misinterpreted the documentation.
Then it seems that -fno-semantic-interposition is a very safe optimization for
distributions to default to. Closing as intended.

I will try changing Clang to drop the local aliases for variables.
It is tricky not to use local aliases for address taking of functions, though.
Fortunately, this will not cause any problems once we do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593

(In reply to H.J. Lu from comment #4)

I will much appreciate it if you want to fix some copy relocations/canonical
PLT entries
issues so that it will be more easy for distributions to switch to something
like a default
-Wl,-Bsymbolic-global-functions.
What does ld.so do for the proposed GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION? Does
it apply to
STB_GLOBAL or also STB_WEAK?
Does it add all definitions to a global namespace to enforce single definition
for every candidate?
If it does the additional check, this would further slow down dynamic linking.

And I believe we should do the function oriented non-interposition-by-default
plan, which will not be blocked by copy relocation elimination.
(https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#copy-relocations)

[Bug c/100483] Extend -fno-semantic-interposition to global variables

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> ---
> Thanks for the clarification. I misinterpreted the documentation.
> Then it seems that -fno-semantic-interposition is a very safe optimization for
> distributions to default to. Closing as intended.

Basically -fno-semantic-interposition is OK unless you want to play
tricks like interposing alternative malloc implementations. This comes
very handy for some low-level libraries but I did not see it being used
for interposing say some QT symbols or so.

Honza