[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 <marlowsd@…>): In [changeset:"c23f057f1753634e2bc0612969470efea6443031/ghc" c23f057f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c23f057f1753634e2bc0612969470efea6443031" Mark code related symbols as @function not @object Summary: This diff is a part of the bigger project which goal is to improve common profiling tools support (perf) for GHC binaries. A similar job was already done and reverted in the past: * https://phabricator.haskell.org/rGHCb1f453e16f0ce11a2ab18cc4c350bdcbd36299a6 * https://phabricator.haskell.org/rGHCf1f3c4f50650110ad0f700d6566a44c515b0548f Reasoning: `Perf` and similar tools build in memory symbol table from the .symtab section of the ELF file to display human-readable function names instead of the addresses in the output. `Perf` uses only two types of symbols: `@function` and `@notype` but GHC is not capable to produce any `@function` symbols so the `perf` output is pretty useless (All the haskell symbols that you can see in `perf` now are `@notype` internal symbols extracted by mistake/hack). The changes: * mark code related symbols as @function * small hack to mark InfoTable symbols as code if TABLES_NEXT_TO_CODE is true Limitations: * The perf symbolization support is not complete after this patch but I'm working on the second patch. * Constructor symbols are not supported. To fix that we can issue extra local symbols which mark code sections as code and will be only used for debug. Test Plan: tests any additional ideas? Perf output on stock ghc 8.4.1: ``` 9.78% FibbSlow FibbSlow [.] ckY_info 9.59% FibbSlow FibbSlow [.] cjqd_info 7.17% FibbSlow FibbSlow [.] c3sg_info 6.62% FibbSlow FibbSlow [.] c1X_info 5.32% FibbSlow FibbSlow [.] cjsX_info 4.18% FibbSlow FibbSlow [.] s3rN_info 3.82% FibbSlow FibbSlow [.] c2m_info 3.68% FibbSlow FibbSlow [.] cjlJ_info 3.26% FibbSlow FibbSlow [.] c3sb_info 3.19% FibbSlow FibbSlow [.] cjPQ_info 3.05% FibbSlow FibbSlow [.] cjQd_info 2.97% FibbSlow FibbSlow [.] cjAB_info 2.78% FibbSlow FibbSlow [.] cjzP_info 2.40% FibbSlow FibbSlow [.] cjOS_info 2.38% FibbSlow FibbSlow [.] s3rK_info 2.27% FibbSlow FibbSlow [.] cjq0_info 2.18% FibbSlow FibbSlow [.] cKQ_info 2.13% FibbSlow FibbSlow [.] cjSl_info 1.99% FibbSlow FibbSlow [.] s3rL_info 1.98% FibbSlow FibbSlow [.] c2cC_info 1.80% FibbSlow FibbSlow [.] s3rO_info 1.37% FibbSlow FibbSlow [.] c2f2_info ... ``` Perf output on patched ghc: ``` 7.97% FibbSlow FibbSlow [.] c3rM_info 6.75% FibbSlow FibbSlow [.] 0x000000000032cfa8 6.63% FibbSlow FibbSlow [.] cifA_info 4.98% FibbSlow FibbSlow [.] integerzmgmp_GHCziIntegerziType_eqIntegerzh_info 4.55% FibbSlow FibbSlow [.] chXn_info 4.52% FibbSlow FibbSlow [.] c3rH_info 4.45% FibbSlow FibbSlow [.] chZB_info 4.04% FibbSlow FibbSlow [.] Main_fibbzuslow_info 4.03% FibbSlow FibbSlow [.] stg_ap_0_fast 3.76% FibbSlow FibbSlow [.] chXA_info 3.67% FibbSlow FibbSlow [.] cifu_info 3.25% FibbSlow FibbSlow [.] ci4r_info 2.64% FibbSlow FibbSlow [.] s3rf_info 2.42% FibbSlow FibbSlow [.] s3rg_info 2.39% FibbSlow FibbSlow [.] integerzmgmp_GHCziIntegerziType_eqInteger_info 2.25% FibbSlow FibbSlow [.] integerzmgmp_GHCziIntegerziType_minusInteger_info 2.17% FibbSlow FibbSlow [.] ghczmprim_GHCziClasses_zeze_info 2.09% FibbSlow FibbSlow [.] cicc_info 2.03% FibbSlow FibbSlow [.] 0x0000000000331e15 2.02% FibbSlow FibbSlow [.] s3ri_info 1.91% FibbSlow FibbSlow [.] 0x0000000000331bb8 1.89% FibbSlow FibbSlow [.] ci4N_info ... ``` Reviewers: simonmar, niteria, bgamari, goldfire Reviewed By: simonmar, bgamari Subscribers: lelf, rwbarton, thomie, carter GHC Trac Issues: #15501 Differential Revision: https://phabricator.haskell.org/D4713 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15501#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC