Comment # 6 on bug 1180610 from Jiri Slaby

(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.