MC currently produces monolithic .gcc_except_table section. GCC can split up .gcc_except_table:
- if comdat: .section .gcc_except_table._Z6comdatv,"aG",@progbits,_Z6comdatv,comdat
- otherwise, if -ffunction-sections: .section .gcc_except_table._Z3fooi,"a",@progbits
This ensures that (a) non-prevailing copies are discarded and (b)
.gcc_except_table associated to discarded text sections can be discarded by a
.gcc_except_table-aware linker (GNU ld, but not gold or LLD)
This patches matches the GCC behavior. If -fno-unique-section-names is
specified, we don't append the suffix. If -ffunction-sections is additionally specified,
use .section ...,unique.
Note, if clang driver communicates that the linker is LLD and we know it
is new (11.0.0 or later) we can use SHF_LINK_ORDER to avoid string table
costs, at least in the -fno-unique-section-names case. We cannot use it on GNU
ld because as of binutils 2.35 it does not support mixed SHF_LINK_ORDER &
non-SHF_LINK_ORDER components in an output section
https://sourceware.org/bugzilla/show_bug.cgi?id=26256
For RISC-V -mrelax, this patch additionally fixes an assembler-linker
interaction problem: because a section is shrinkable, the length of a call-site
code range is not a constant. Relocations referencing the associated text
section (STT_SECTION) are needed. However, a STB_LOCAL relocation referencing a
discarded section group member from outside the group is disallowed by the ELF
specification (PR46675):
// a.cc inline int comdat() { try { throw 1; } catch (int) { return 1; } return 0; } int main() { return comdat(); } // b.cc inline int comdat() { try { throw 1; } catch (int) { return 1; } return 0; } int foo() { return comdat(); } clang++ -target riscv64-linux -c a.cc b.cc -fPIC -mno-relax ld.lld -shared a.o b.o => ld.lld: error: relocation refers to a symbol in a discarded section:
-fbasic-block-sections= is similar to RISC-V -mrelax: there are outstanding relocations.
Should this instead inherit the (base) flags from LSDASection? For CHERI we have to add SHF_WRITE (we make it a relro section) so it'd be nice to inherit that automatically here rather than needing to have the logic duplicated between here and initELFMCObjectFileInfo.