[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 needed
          Component:  Compiler       |           Version:  8.5
  (CodeGen)                          |
           Keywords:  perf,          |  Operating System:  Linux
  symbols, elf, linux                |
       Architecture:                 |   Type of failure:  Debugging
  Unknown/Multiple                   |  information is incorrect
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):  D4713          |         Wiki Page:
-------------------------------------+-------------------------------------
 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>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler