Traditionally, it has been defined in crtbegin.o, which is typically provided by libgcc or as part of the C library on some systems. However, but there's no principled reason for it to be there. We optionally define this symbol, which can be used on platforms that don't provide __dso_handle in crtbegin.o or which don't use crtbegin.o at all.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
There is a related discussion in http://lists.llvm.org/pipermail/llvm-dev/2017-June/113648.html thread.
Overall looks fine. I think this is the right approach to define __dso_handle, as it is very easy to do, compared to other solutions.
ELF/Writer.cpp | ||
---|---|---|
910 | I'd describe a bit more about the __dso_handle symbol so that the code is more self-contained for the first-time reader of the source code. Specifically, I'd like to mention
In particular, "... with a value which is an address in one of the object's segment" sounds too formal specification-ish. I'd make it more concrete. | |
913 | Don't you want to do this only when Config->Shared? |
ELF/Writer.cpp | ||
---|---|---|
913 | The frontend generates the __dso_handle reference in any case because it doesn't whether the code is going to be linked into a shared library or not so we need to generate this symbol even in the non-shared case. |
ELF/Writer.cpp | ||
---|---|---|
910 | Remove an extra space. |
I'd describe a bit more about the __dso_handle symbol so that the code is more self-contained for the first-time reader of the source code. Specifically, I'd like to mention
In particular, "... with a value which is an address in one of the object's segment" sounds too formal specification-ish. I'd make it more concrete.