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

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 16 16:16:01 PDT 2020


pcc added inline comments.


================
Comment at: lld/MachO/Symbols.h:139
+
+  static const constexpr StringRef name = "___dso_handle";
+
----------------
int3 wrote:
> compnerd wrote:
> > int3 wrote:
> > > int3 wrote:
> > > > int3 wrote:
> > > > > pcc wrote:
> > > > > > compnerd wrote:
> > > > > > > What do you think of making this ever so slightly more expensive?  I think that we should actually make this computed - the name of the symbol is `__dso_handle` which is decorated with the user label prefix of `_` to give you `___dso_handle`.  We have the information about the user label prefixes in LLVM, why not make that explicit here?  I don't think that the cost is really that high.
> > > > > > FWIW, in general I'm not a fan of the idea of computing string constants like this, as it makes it harder to grep the code for strings like `___dso_handle`.
> > > > > I wasn't aware that LLVM had info about user label prefixes (though that makes sense). Happy to change. I suppose I'll want something like `getTargetInfo().getDataLayout().getGlobalPrefix()`
> > > > hmm `DataLayout` is under the `IR` folder though. I'm not sure how else to get at the user label, but we could probably just make it a global constant in lld-macho since the prefix applies to all macOS targets?
> > > saw @pcc's comment later on, and I think it's a good reason to keep `__dso_handle`... also it's nice to be able to write the string inline in the class declaration rather than in the .cpp file.
> > I'm suggesting that we keep `__dso_handle` which is still grepable, the prefix itself which is a single `_` which is what I was suggesting that we remove.  I suppose that its not the end of the world if we don't split it up, but using the `IRMangler` in LLVM is pretty common place and seems more precise/easier to understand to me.
> I tried grepping for `IRMangler` and didn't find anything (and found a lot of results grepping for `mangle`). Which class were you thinking of?
If your starting point is `___dso_handle` (for example, if you see that in `nm` output), it doesn't really help that `__dso_handle` is greppable.

I would also say that it makes the code harder to understand, by adding an unnecessary level of indirection. In order to understand what `mangle("__dso_handle")` does I would need to read the definition of `mangle` and establish that it always just prepends `_` on Mach-O, so I know that it always returns `"___dso_handle"`. But if I just see `"___dso_handle"` I get that knowledge straight away.

Anyway, I don't have much of a horse in this race, that's just my viewpoint.


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