This is an archive of the discontinued LLVM Phabricator instance.

Bring back r307364
Needs ReviewPublic

Authored by espindola on Jul 18 2017, 5:53 PM.

Details

Summary

This includes an extra hack to handle a file having both foo and foo@@ver.

Another option is checking with the user if they can juts change their code. For what it is worth it, gold produces the same result as the original patch.

With this patch we produce the same result as bfd.

Diff Detail

Event Timeline

rafael created this revision.Jul 18 2017, 5:53 PM
ruiu added inline comments.Jul 18 2017, 6:00 PM
ELF/SymbolTable.cpp
246

We also reach here if foo and foo@ver come from different input file, no?

ELF/Symbols.h
148

I wouldn't remove this because I want to hide the fact that the name is represented as StringRefZ instead of StringRef from outside of this class.

Actually, given how symver works I am pretty much convinced that having foo and foo@@ver in the same .o file is the only way to handle versioning without having to copy symbol names to a version scirpt.

Handy Phabricator link: rL307364

So this case just doesn't work with gold?

This should address the review comments.

Given that this effectively requires foo to be weak in

.symver foo, foo@@bar

I will try an alternative solution too.

I'm probably just misunderstanding the discussion here, but bfd complains about multiple definitions if you do .symver x, x@@VER: https://ghostbin.com/paste/c9b4t. Granted, I'm on an old version of binutils, so maybe that's changed?

(from @rafael's email) Correct, bfd complains. That is why you have to make foo weak, which is annoying.

Okay, that makes sense. Are we not necessarily trying to mimic bfd's behavior then?

I'm slightly confused in general (and I apologize for jumping in without having the full context, but I've had to deal a bunch of symbol versioning issues internally, and I'm also working on switching things over to LLD, so I want to make sure I understand LLD's intended behavior for versioning). From what I understand, this patch is meant to restore https://reviews.llvm.org/D35059 while fixing the case in https://bugs.llvm.org/show_bug.cgi?id=33820. Shouldn't there be an additional test case for the issue in that bug? As far as I can see the test cases here are the same as the ones from https://reviews.llvm.org/D35059.

ELF/SymbolTable.cpp
246

This is meant to address the case from https://bugs.llvm.org/show_bug.cgi?id=33820, right?

Thanks for the explanations @rafael. Everything makes sense now.

As someone not super familiar with LLD's code, I find D35612 a lot easier to understand. Both work fine for all the cases I was concerned with, however. Thanks.

espindola commandeered this revision.Mar 15 2018, 8:47 AM
espindola added a reviewer: rafael.
espindola edited reviewers, added: espindola; removed: rafael.Mar 15 2018, 9:15 AM