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

Thu Jul 30 12:13:07 PDT 2020

int3 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.
----------------
smeenai wrote:
> 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.
oh, I'd thought you were talking about the local-defined symbol. Yeah giving an explicit error for the global one wouldn't be a bad idea

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83603