Fixes the main issue in PR41693
When both modes are used, two functions are created:
sancov.module_ctor, sancov.module_ctor.$LastUnique, where
$LastUnique is the current LastUnique counter that may be different in
another module.
sancov.module_ctor.$LastUnique belongs to the comdat group of the same
name (due to the non-null third field of the ctor in llvm.global_ctors).
COMDAT group section [ 9] `.group' [sancov.module_ctor] contains 6 sections: [Index] Name [ 10] .text.sancov.module_ctor [ 11] .rela.text.sancov.module_ctor [ 12] .text.sancov.module_ctor.6 [ 13] .rela.text.sancov.module_ctor.6 [ 23] .init_array.2 [ 24] .rela.init_array.2 # 2 problems: # 1) If sancov.module_ctor in this module is discarded, this group # has a relocation to a discarded section. ld.bfd and gold will # error. (Another issue: it is silently accepted by lld) # 2) The comdat group has an unstable name that may be different in # another translation unit. Even if the linker allows the dangling relocation # (with --noinhibit-exec), there will be many undesired .init_array entries COMDAT group section [ 25] `.group' [sancov.module_ctor.6] contains 2 sections: [Index] Name [ 26] .init_array.2 [ 27] .rela.init_array.2
By using different module ctor names, the associated comdat group names
will also be different and thus stable across modules.
Can we add an assert that the name of CtorFunc matches CtorName?