https://bugs.llvm.org/show_bug.cgi?id=48820
Fangrui Song <i...@maskray.me> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Fangrui Song <i...@maskray.me> ---
There is a design flaw in .symver @ design.
In bad.c, `.symver foo, foo@v1` + defined foo cause both foo and foo@v1.
GNU ld has a special rule: if 'foo@v1' is defined, foo is suppressed. The 'foo'
pattern in version node VERS.1 in foo.v does not produce foo or foo@@v1.
In gold, if VERS.1 is empty, .dynsym has both foo and foo@VERS.1
If VERS.1 has foo, .dynsym has just foo@VERS.1
In LLD, if VERS.1 is empty, .dynsym has both foo and foo@VERS.1
If VERS.1 has foo, .dynsym has foo@@VERS.1 and foo@VERS.1. This causes the
executable foo reference to be bound to foo@VERS.1 and fail the test.
I have actually filed a bug against GNU ld:
https://sourceware.org/bugzilla/show_bug.cgi?id=27210
and analyzed that **dropping the special rule from GNU ld will be safe.**
However, there has been no satisfactory answer.
The reaction probably gives a casual reader such a feeling:
"GNU ld has implemented this, and we don't want to drop a so you other linkers
need to follow."
(GNU ld implements version symbols via the intricate indirect symbol mechanism,
so perhaps dropping the rule is difficult.)
In any case I don't think this could cause problem in practice because
non-default versions should use a different symbol name (i.e. use something
like .symver foo_v1, foo@v1 instead of .symver foo, foo@v1) anyway.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
