[llvm-bugs] [Bug 48820] .symver foo, foo at v1 is mishandled

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jan 20 19:25:58 PST 2021


https://bugs.llvm.org/show_bug.cgi?id=48820

Fangrui Song <i at maskray.me> changed:

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

--- Comment #1 from Fangrui Song <i at maskray.me> ---
There is a design flaw in .symver @ design.

In bad.c, `.symver foo, foo at v1` + defined foo cause both foo and foo at v1.
GNU ld has a special rule: if 'foo at 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 at VERS.1
If VERS.1 has foo, .dynsym has just foo at VERS.1

In LLD, if VERS.1 is empty, .dynsym has both foo and foo at VERS.1
If VERS.1 has foo, .dynsym has foo@@VERS.1 and foo at VERS.1. This causes the
executable foo reference to be bound to foo at 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 at v1 instead of .symver foo, foo at v1) anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210121/7325169b/attachment.html>


More information about the llvm-bugs mailing list