[PATCH] D102453: [CMake][ELF] Add -fno-semantic-interposition for GCC

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 14 20:57:59 PDT 2021


MaskRay added a comment.

In D102453#2761165 <https://reviews.llvm.org/D102453#2761165>, @foutrelis wrote:

> Is it possible that future GCC versions would optimize global variables like Clang does when -fno-semantic-interposition is used?
>
> (Apologies in advance if this question is silly and/or the answer is obvious.)

This is a good question:) (and one goal I started these conversations: make distributions interested.)

Will GCC switch to the Clang model? I do not recommend it. The Clang tri-state is actually a bit confusing.

I wish that the ELF world can shift to default -fno-semantic-interposition and (in the long term) -Wl,-Bsymbolic-functions, bring back the lost performance for decades.
Such interposition doesn't work with macOS (by default) and Windows, so these is good change that most pieces of portable software are already in a good state.
However, I can imagine that there is still a decent amount of work. Distributions need to put into resources (likely less than the -fno-pic->-fPIE transition (GCC's --enable-default-pie)).
In return, **shared objects will be no slower than static PIE**.

Will GCC be able to change the default? Ultimately I think that will be a distribution's decision.
**When sufficient distributions switch to -fno-semantic-interposition by default, maybe the upstream GCC switch will happen as well.**

There is a trade-off and the downside is that LD_PRELOAD replacing a fragment of a shared object will be unsupported.
In some rare cases the user may need LD_PRELOAD: sometimes as a workaround for some broken software. I feel that distributions should not provide such flexibility by default at such a great cost.
The users can build the software by themselves.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102453/new/

https://reviews.llvm.org/D102453



More information about the llvm-commits mailing list