https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126841
--- Comment #2 from Longjun Luo <luolongjuna at gmail dot com> --- (In reply to Drea Pinski from comment #1) > I dont see anything wrong with what is happening here. > > Yes it happens to be in the same section but that would have happened > without lto too. > > How did you notice this? Because nothing here signifies there is anything > linking incorrectly either. Thanks for taking a look. I agree that this does not cause incorrect linking. My concern is narrower: the behavior of -ffunction-sections at the compiler-produced relocatable object boundary, before the final link. I checked the same testcase without LTO. Each compilation produces a separate native object: a.o: same_fn -> .text.same_fn b.o: same_fn -> .text.same_fn c.o: same_fn -> .text.same_fn Each physical input object therefore contains exactly one function in its own function section. The final shared object naturally merges these input sections into .text, but that is linker output and is not the boundary I am reporting. With full LTO, the compiler-produced LTRANS assembly/native ET_REL instead contains: same_fn.lto_priv.0 -> .text.same_fn.lto_priv.0 same_fn.lto_priv.1 -> .text.same_fn, offset 0x0 same_fn.lto_priv.2 -> .text.same_fn, offset 0x10 Thus, before the final link, two distinct function bodies with distinct assembler names already occupy one physical input section. This seems inconsistent with the documented description of -ffunction-sections: "Place each function or data item into its own section in the output file ... The name of the function or the name of the data item determines the section's name in the output file." I noticed this while developing a user-space live-patching build tool. The tool captures compiler-produced native ET_REL contributors before the final link and relies on -ffunction-sections to preserve per-function patch granularity. Its section-ownership validation detected this case in a Fedora Valkey full-LTO build. So the report is not about a link failure. It is about the LTO compiler output no longer preserving the per-function section contract. In particular, after LTO privatization the functions have distinct assembler names, but two of them retain the common .text.same_fn section name.
