This fixes PR49198: Wrong usage of __dso_handle in user code leads to a compiler
crash.
When Init is an address of the global itself, we need to track it
across RAUW. Otherwise the initializer can be destroyed if the global
is replaced.
Differential D101156
[Clang] Support a user-defined __dso_handle asavonic on Apr 23 2021, 5:19 AM. Authored by
Details
This fixes PR49198: Wrong usage of __dso_handle in user code leads to a compiler When Init is an address of the global itself, we need to track it
Diff Detail
Event TimelineComment Actions John, can you please review this patch? Comment Actions What's the crash exactly/ Is IRGen just unhappy about processing the user definition when we've generated a declaration with a different type? Because we're already supposed to be being cautious about this. Comment Actions Hi John. Sorry for the late reply. class a { public: ~a(); } b; void *__dso_handle = &__dso_handle; This code code causes a crash because the compiler first generates a @__dso_handle = external dso_local global i8 ... and then reaches the explicit definition of it with a pointer type and a @__dso_handle = hidden global i8* bitcast (i8** @__dso_handle to i8*), align 8 Since __dso_handle already exists in the module, it must be replaced because the There is indeed some handling for this case in EmitGlobalVarDefinition, but it p Init->dump() <badref> = hidden global i8 <null operand!> The current patch avoids this problem by having two distinct globals, but maybe Comment Actions I went ahead and implemented a fix for EmitGlobalVarDefinition. Please let me know what approach is preferable: Diff 339986 or Diff 347341.
Comment Actions i have a problem i'am implement a libc in c++ i can't export now __dso_handle as weak so I can't link other shared libs against my libc. |
Can we actually do this bitcast for arbitrary initializers? This seems problematic.
I think we just need to hold Init in an llvm::TrackingVH across the call to GetAddrOfGlobalVar.