[PATCH] D83603: [lld-macho] Support __dso_handle for C++

Shoaib Meenai via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 30 11:55:42 PDT 2020


smeenai added inline comments.


================
Comment at: lld/test/MachO/dso-handle-no-override.s:3-7
+## If for some bizarre reason the input file defines its own ___dso_handle, we
+## should ignore it. At least, we've implemented this behavior if the
+## conflicting symbol is a global. A local symbol of the same name will still
+## take priority in our implementation, unlike in ld64. But that's a pretty
+## far-out edge case that should be safe to ignore.
----------------
int3 wrote:
> smeenai wrote:
> > What do you think about giving an explicit error vs. silently ignoring the user-defined symbol?
> > 
> > The local symbol thing is unfortunate, but I don't see a good way to handle it. (Plus I think symbols beginning with double underscores are supposed to be reserved for the implementation, so if a user has their own `__dso_handle` symbol they're in undefined territory anyway.)
> Giving an explicit error is not much less complicated than discarding it in favor of `__dso_handle` -- we'd still need to make the `createDefined` function check that every symbol it's creating doesn't have that name. Not difficult, just ugly...
Not sure I follow? We're calling `addDSOHandle` after all the input files have been read (and their symbols added to the symbol table), correct? In that case, we'd just need to check that no symbol with that name already existed when we inserted it. Unless you meant to handle local symbols, in which case, I agree that seems ugly and probably not worth it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83603/new/

https://reviews.llvm.org/D83603



More information about the llvm-commits mailing list