[GHC] #15501: Fix unknown symbols/addresses in perf output

[GHC]

#15501: Fix unknown symbols/addresses in perf output
-------------------------------------+-------------------------------------
        Reporter:  last_g            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  Research
       Component:  Compiler          |  needed
  (CodeGen)                          |              Version:  8.5
      Resolution:                    |             Keywords:  perf,
                                     |  symbols, elf, linux
Operating System:  Linux             |         Architecture:
 Type of failure:  Debugging         |  Unknown/Multiple
  information is incorrect           |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  D4713
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by bgamari:

Old description:

> After https://phabricator.haskell.org/D4713 will be merged some addresses
> in perf output won't be mapped to the symbols.
> This needs investigation and fix.
>
> A draft idea about the root cause:
>
> The issue comes from the current perf symbolization algorithm.
>
> The basic logic is (kind of) simple:
>
> # Take all the @function symbols and put into a sorted list;
> # the next steps are a hack to support handwritten assembly
> # Take all the NOTYPE symbols with the size equals to 0 and put into the
> same ordered list;
> # Run the symbols__fixup_end procedure which sets a symbol end address to
> be the beginning of the next symbol for every 0 sized symbol;
> # If the last symbol is zero sized: set its size to be ~4k.
> (The actual logic is more complicated because it also involves
> sections&map groups)
>
> In GHC compiled binaries there are no @function symbols and most internal
> symbols are NOTYPE and 0 sized so we are ending up in the hack's code.
>
> This logic effectively means that every address in our code space is
> attributed to some internal symbol (correct or not). Adding @function
> symbols with size directive stops this from happening.
> As the first guess, those addresses can come from _con_info entries which
> we don't mark as @function but in that case, there should be no unknown
> addresses in D4730 but we have some there too.

New description:

 After https://phabricator.haskell.org/D4713 will be merged some addresses
 in perf output won't be mapped to the symbols.
 This needs investigation and fix.

 A draft idea about the root cause:

 The issue comes from the current perf symbolization algorithm.

 The basic logic is (kind of) simple:

 {{{
 # Take all the @function symbols and put into a sorted list;
 # the next steps are a hack to support handwritten assembly
 # Take all the NOTYPE symbols with the size equals to 0 and put into the
 same ordered list;
 # Run the symbols__fixup_end procedure which sets a symbol end address to
 be the beginning of the next symbol for every 0 sized symbol;
 # If the last symbol is zero sized: set its size to be ~4k.
 (The actual logic is more complicated because it also involves
 sections&map groups)
 }}}

 In GHC compiled binaries there are no @function symbols and most internal
 symbols are NOTYPE and 0 sized so we are ending up in the hack's code.

 This logic effectively means that every address in our code space is
 attributed to some internal symbol (correct or not). Adding @function
 symbols with size directive stops this from happening.
 As the first guess, those addresses can come from _con_info entries which
 we don't mark as @function but in that case, there should be no unknown
 addresses in D4730 but we have some there too.

--

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15501#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler