https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126841
--- Comment #4 from Longjun Luo <luolongjuna at gmail dot com> --- (In reply to Drea Pinski from comment #3) > For live patching different sections is not going to help and you need to > disable most of ipa passes. So there is nothing to be done here. The live-patching context was only an answer to “How did you notice this?”. It is not the correctness criterion for this report, and I am not claiming that -ffunction-sections alone makes arbitrary optimized code live-patchable. I am also not asking GCC to disable IPA passes or to preserve every source function. IPA is free to inline, clone, fold, split, or remove functions. In this case, however, after IPA GCC has chosen to emit two separate, address-bearing STT_FUNC bodies: same_fn.lto_priv.1 at offset 0x0 same_fn.lto_priv.2 at offset 0x10 They have distinct assembler names and distinct bodies, but GCC emits them under one physical section. Our tool operates on post-optimization native object code and separately accounts for compiler transformations. Separate sections are useful as object-code and relocation units, although they are clearly not sufficient by themselves to implement live patching. The question for this report is therefore independent of the live-patching design: When -ffunction-sections is enabled, is GCC intentionally allowed to place multiple distinct post-IPA emitted functions into one compiler-generated section? If that is the intended contract, then the current documentation may need to clarify that -ffunction-sections is only best-effort across IPA transformations. Otherwise, retaining the pre-privatization implicit section name appears to be the issue described here.
