The C++ ABI requires dylibs to pass a pointer to __cxa_atexit which does
e.g. cleanup of static global variables. The C++ spec says that the pointer
can point to any address in one of the dylib's segments, but in practice
ld64 seems to set it to point to the header, so that's what's implemented
here.
Details
- Reviewers
smeenai - Group Reviewers
Restricted Project - Commits
- rG3587de228198: [lld-macho] Support __dso_handle for C++
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/MachO/SymbolTable.cpp | ||
---|---|---|
101 | Debugging left overs? | |
lld/MachO/Symbols.h | ||
150 | 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. |
lld/MachO/Symbols.h | ||
---|---|---|
150 | 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() |
lld/MachO/Symbols.h | ||
---|---|---|
150 | 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? |
lld/MachO/Symbols.h | ||
---|---|---|
129 | yeah I wasn't super sure what the right names for these things were -- I thought the document describing the ABI would be considered a spec -- but I guess 'spec' connotes 'language spec'... |
lld/MachO/Symbols.h | ||
---|---|---|
150 | 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. |
lld/MachO/Symbols.h | ||
---|---|---|
150 | 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? |
lld/MachO/Symbols.h | ||
---|---|---|
150 | 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. |
lld/MachO/Symbols.h | ||
---|---|---|
150 | I agree that having literal 3-underline ___dso_handle helps with grepping. |
lld/MachO/Symbols.h | ||
---|---|---|
150 | I'm good with leaving the underscore in. | |
lld/test/MachO/dso-handle-no-override.s | ||
3–7 ↗ | (On Diff #278376) | 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.) |
lld/test/MachO/dso-handle-no-override.s | ||
---|---|---|
3–7 ↗ | (On Diff #278376) | 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... |
lld/test/MachO/dso-handle-no-override.s | ||
---|---|---|
3–7 ↗ | (On Diff #278376) | 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. |
lld/test/MachO/dso-handle-no-override.s | ||
---|---|---|
3–7 ↗ | (On Diff #278376) | 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 |
Debugging left overs?