This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Do not allow mix global symbols version.
ClosedPublic

Authored by grimar on Jun 21 2016, 6:11 AM.

Details

Summary

For next version script:

VER1{
  global:
  a;
};

VER2{
  global:
  a;
};

gold would produce warning like:
"warning: using 'VER1' as version for 'a' which is also named in version 'VER1' in script."

Documentation also says we do not want this duplications (https://people.freebsd.org/~deischen/symver/library_versioning.txt):
"Note that you do not want to duplicate symbols in the map file. The .symver directives are all that is required to add compatibility
symbols into old versions."

So I suggest to error out such cases.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar updated this revision to Diff 61362.Jun 21 2016, 6:11 AM
grimar retitled this revision from to [ELF] - Do not allow duplicate global symbols version..
grimar updated this object.
grimar added reviewers: ruiu, rafael.
grimar added subscribers: llvm-commits, grimar.
grimar retitled this revision from [ELF] - Do not allow duplicate global symbols version. to [ELF] - Do not allow mix global symbols version..Jun 21 2016, 6:12 AM
davide added a subscriber: davide.Jun 21 2016, 9:02 AM

I was a little bit confused when I originally tried versioning and noticed you can (both in gold and bfd) duplicate symbols in the map. The fact they just emit a warning (and not an error) makes me think there's some software in the wild which abuses of this feature.

That said, I entirely advocate being a little bit more strict, but, I'd rather finish the version script support (or at least make it good enough that it can understand FreeBSD base system, large C++ applications etc..) before introducing these restrictions.
If you want a large test case, you can try linking gentoo packages/FreeBSD packages. I tried the latter and realized many failures happened in version script support (e.g. comments not parsed correctly).

tl;dr: I'd rather put this on hold until we got the basics right, or at least until we realized being more strict doesn't cause additional headache down the road. YMMV.

rafael accepted this revision.Jun 21 2016, 12:48 PM
rafael edited edge metadata.

I disagree with Davide on this one.

The code is very simple and can be easily reverted if we find scripts depending on it. While that, having this restriction makes it easier to reason about the rest of the implementation without having to think what the correct behaviour is when a symbol is in two versions.

ELF/SymbolTable.cpp
535 ↗(On Diff #61362)

Using > with an opaque constant is a bit odd. Please use !=.

This revision is now accepted and ready to land.Jun 21 2016, 12:48 PM

I agree with @rafael. It's easy to revert later if necessary and I'd rather we default to erroring out on bogus input until/unless we identify some 3rd party software that depends on it for a non-accidental reason and it cannot be fixed.

ruiu accepted this revision.Jun 21 2016, 4:00 PM
ruiu edited edge metadata.

LGTM

Fair enough, let's see how this works and revert if needed.

This revision was automatically updated to reflect the committed changes.

Hmm, I think this breaks libreoffice, sorry.

duplicate symbol _ZThn32_N4cppu16OComponentHelper14queryInterfaceERKN3com3sun4star3uno4TypeE in version script
duplicate symbol _ZThn48_N4cppu16OComponentHelper14queryInterfaceERKN3com3sun4star3uno4TypeE in version script
duplicate symbol _ZThn56_N4cppu16OComponentHelper14queryInterfaceERKN3com3sun4star3uno4TypeE in version script

cppuhelper/source/gcc3.map lists multiple times the same symbol :(
https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=cppuhelper/source/gcc3.map;h=12c29834ab1687d5747808b8a308e550962e6721;hb=refs/heads/master

_ZThn*_N4cppu16OComponentHelper7acquireEv;

It's actually even worse than that, the symbol is *defined* multiple times under the same version. I think they should fix their version script (and in fact I plan to propose a change upstream), but in the time being, I'd rather switch this back to a warning. I'm sending a patch soon.