[GHC] #15501: Fix unknown symbols/addresses in perf output
#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
#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
#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: |
-------------------------------------+-------------------------------------
Comment (by Simon Marlow
participants (1)
-
GHC