[PATCH] D136381: [ELF] Suppress "duplicate symbol" when resolving STB_WEAK and STB_GNU_UNIQUE in different COMDATs

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 21 09:38:17 PDT 2022


MaskRay marked an inline comment as done.
MaskRay added a comment.

In D136381#3874126 <https://reviews.llvm.org/D136381#3874126>, @peter.smith wrote:

> Is this symptomatic of a problem in Clang or GCC? It looks like they are not generating the same groups for the same source file which I would expect considering that both claim to implement the itanium ABI. I couldn't understand at first why the STB_GNU_UNIQUE symbols were not getting discarded as part of a non-prevailing group, however the clang and gcc (I used aarch64-none-linux-gnu-g++ (fsf-10.39) 10.1.1 20200629) generated groups have different signatures so we end up with two groups with one STB_GNU_UNIQUE and one STB_WEAK.

I need to do some research. I suspect GCC's scheme isn't ideal as generally we want to make related symbols in one comdat instead of two.

> I've approved as the groups are different even when `-fno-gnu-unique` is used for GCC so it makes sense to treat STB_GNU_WEAK and STB_GNU_UNIQUE the same way. However this does feel less than ideal. We end up with sections from both groups in the ELF file but only one set of symbols. Probably the job of the compiler to fix, not sure there is much we can do at link time.

The mix is not ideal but appear to work fine in practice because the guard variable prevents harm due to double initialization....
For the linker we just stick with the rule that a weak binding does not cause duplicate symbol error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136381



More information about the llvm-commits mailing list