https://bugzilla.suse.com/show_bug.cgi?id=1180610 https://bugzilla.suse.com/show_bug.cgi?id=1180610#c6 --- Comment #6 from Jiri Slaby <jslaby@suse.com> --- (In reply to Richard Biener from comment #5)
These symbols are an "artifact" of how LTO handles debuginfo. One could argue that the process of splitting the debuginfo to the separate file is broken since it leaves those stray symbols in the main file making it technically an invalid ELF file
It's .debug containing these references to its sections, but perf resolves only against main (runtime) file.
(I'd have to see what the extraction actually does to the "source" ELF).
From /usr/lib/rpm/find-debuginfo.sh: Copy to X.debug:
objcopy --only-keep-debug "$f" "$debugfn" Strip X: objcopy --add-gnu-debuglink="$debugfn" -R .comment -R .GCC.command.line $strip_option "$f"
where strip_option="--strip-all" in most cases, exceptions have --strip-debug.
I'm not sure just looking up STT_FUNC symbols is "correct". Instead I'd argue that WEAK symbols that fail to be resolved should be ignored.
The question is if we should resolve against .debug, when the section is not in runtime. In that case, what assures that the section number is meant to point to .debug. I mean: runtime before split: [1] .text [2] .data [3] .debuginfo [4] .shstrtab runtime after split: [1] .text [2] .data [3] .shstrtab debug after split: [1] .text [2] .data [3] .debuginfo [4] .shstrtab If debug's .debuginfo points to section 2 it means .data in both split runtime and debug. If it points to section 3, it means .debuginfo in the runtime original, but .shstrtab in runtime split. -- You are receiving this mail because: You are on the CC list for the bug.