[llvm-bugs] [Bug 49274] New: Debug info needs correct symbol ranges

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49274

            Bug ID: 49274
           Summary: Debug info needs correct symbol ranges
           Product: lld
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: jezreel at gmail.com
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

The N_FUN entries in our STABS debug info require us to emit where functions
start and end. Right now we don't have accurate information on where a function
symbol ends. As https://reviews.llvm.org/D89257 says:

> Additionally, this current implementation doesn't accurately reflect the size
of function symbols. It uses the size of their containing sections as a proxy,
but that is only accurate if .subsections_with_symbols is set, and if there
isn't an N_ALT_ENTRY in that particular subsection.

I am not sure how ld64 handles this. I initially suspected we should sort the
symbols in our InputFiles by address order, and use the start of the next
symbol to determine the end of the current one. But I'm wondering if perhaps we
should use the compact unwind info generated by `.cfi_endproc` instead. (`xcrun
unwinddump` does show that the unwind info contains information about function
size.) Let's figure out what ld64 is doing...

If we do end up sorting the list in input symbols, we should rewrite
`ObjFile::parseSymbols` to take advantage of it (as a follow-up task). Right
now that method splits up sections so that each one coincides with the start of
a symbol. It does this assuming that the list of symbols is unsorted, and could
likely be made faster if we had pre-sorted the list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210219/b1a2de53/attachment.html>