We have several large binaries that are failing to link due to relocation out of range in .rodata. I noticed that the majority of .rodata symbols are symbolicated as <internal>, lld/ELF/InputFiles.cpp suggests these symbols don’t belong to any input files and my best guess is they are some kind of synthetic sections generated by the linker, but I’m not sure what kinds of read-only data would be generated by the linker. What common sources do .rodata <internal> symbols come from?
You likely see a MergeSyntheticSection section (used by a feature: duplicate elimination of SHF_MERGE sections). Such synthetic sections are likely displayed as <internal>:(.rodata) in a link map (-M, -Map). I just created ⚙ D149466 [ELF] Name MergeSyntheticSection using an input section instead of the output section to rename MergeSyntheticSection with the first input section name, but that won’t change <internal>.
Currently we use <internal> to name a section with a nullptr file. Ideally we should associate such sections with one or more dummy InputFile objects with more meaningful names. This refactoring will unfortunately be quite difficult as the file nullness checks are done in many places…
I’ve seen overflows due to .text <-> .rodata relocations, but they are rare.
Overflows due to .text <-> .data/.bss relocations are more common.
I think an effective way is to name large sections .lrodata/.ldata/.lbss as GCC does for -mcmodel=medium. I want to have a GCC clarification whether they want that apply to -mcmodel=large as well ([PATCH] i386: Allow -mlarge-data-threshold with -mcmodel=large).
1 Like