https://sourceware.org/bugzilla/show_bug.cgi?id=33577
--- Comment #24 from Fangrui Song <i at maskray dot me> --- (In reply to Ali Bahrami from comment #17) > The old behavior was wrong, as was beaten to death in the > preceding discussion. Hence, not sensible. Undefined > symbols can't belong to a symbol definition version. > > I do understand that having something that seemed to > be stable change can be annoying to deal with, but the > assumption that version 0 was only for definitions isn't > right. Version 0 is for completely unversioned symbols. There are follow-up discussions on the patch thread https://inbox.sourceware.org/binutils/came9roqz_+wsjuc_arju-o1c5b-cl836kqts4vpjjxmnjzg...@mail.gmail.com/T/#m08dfe58e142eb12396ce73322bc7cc4bf3584bde Andreas Schwab and Michael Matz seem to agree with the old behavior (index 1) as well. While the statement that "non-zero indexes are for defined symbols" is legitimate for Solaris, I maintain my strong arguments that "version 0 (VER_NDX_LOCAL) used to be exclusively for defined symbols" and that "an absent symbol versioning section (like .gnu.version) meant everything was version 1." I don't think it's worth changing the reasonable GNU ld behavior implemented before 1999. ( Linker needs to know the versions of undefined symbols in shared object files for two reasons: (see https://reviews.llvm.org/D80059) - Export a versioned symbol referenced by a shared object, if it is defined in the executable - Make --no-allow-shlib-undefined work for versioned symbols referenced by a shared object in another object file I believe in most ELF linkers, zero index for undefined symbols will lead to more code. ) -- You are receiving this mail because: You are on the CC list for the bug.
