GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-11-25T22:03:34Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10915Statistical profiling support in the RTS2023-11-25T22:03:34ZBen GamariStatistical profiling support in the RTSNow since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling.
While ideally we would be able to rely on exter...Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling.
While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack.
A more feasible alternative is to incorporate a simple statistical profiler into the RTS.
Profiling is defined loosely here as the collection of information describing the current state of evaluation in response to certain triggers. In practice this will be the collection of the current symbol being evaluated triggered on a few events of interest,
- Memory allocation
- Periodic timers for time-based profiling
- Blackhole blocking for locating performance problems due to sharing in parallel programs8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/10985When a "non-exhaustive pattern"-error occurs, output the arguments (if possible)2019-07-07T18:32:47ZWatercrystalWhen a "non-exhaustive pattern"-error occurs, output the arguments (if possible)For Haskell-beginners like me, "non-exhaustive pattern"-errors occur rather often and they can take some time to fix. While it is obvious that one has made a critical mistake when writing a function, I don't think adding some debugging h...For Haskell-beginners like me, "non-exhaustive pattern"-errors occur rather often and they can take some time to fix. While it is obvious that one has made a critical mistake when writing a function, I don't think adding some debugging help would certainly not be bad. I know that this feature only really makes sense when working with types that are instances of `Show`, but then again beginners find themselves working with these types.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"When a \"non-exhaustive pattern\"-error occurs, output the arguments (if possible)","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"For Haskell-beginners like me, \"non-exhaustive pattern\"-errors occur rather often and they can take some time to fix. While it is obvious that one has made a critical mistake when writing a function, I don't think adding some debugging help would certainly not be bad. I know that this feature only really makes sense when working with types that are instances of `Show`, but then again beginners find themselves working with these types.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11261Implement DWARF debugging on powerpc642021-09-07T15:27:56ZPeter Trommlerptrommler@acm.orgImplement DWARF debugging on powerpc64debug:
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151219 for powerpc64-unknown-linux):
dwarfReturnRegNo: Unsupported platform!
CallStack (from ImplicitParams):
error, called at compiler/nativeGen/...debug:
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151219 for powerpc64-unknown-linux):
dwarfReturnRegNo: Unsupported platform!
CallStack (from ImplicitParams):
error, called at compiler/nativeGen/Dwarf/Constants.hs:224:19 in ghc:Dwarf.Constants
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Provide DWARF constants for registers.
Still TODO:
- [ ] add unwinding information to `StgCRun` to ensure that the unwinder can unwind from Haskell into C
- [ ] to support the RTS unwinder: add support to the initial register callback `set_initial_registers` in `rts/Libdw.c`
- [ ] Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`)
- [ ] Support in the native code generator (by implementing the `extractUnwindPoints` field of `NcgImpl`)
- [ ] Unwinding support in `libdw`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | debug, T10667 |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement DWARF debugging on powerpc64","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.11","keywords":[],"differentials":[],"test_case":"debug, T10667","architecture":"","cc":[""],"type":"Bug","description":"debug:\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20151219 for powerpc64-unknown-linux):\r\n dwarfReturnRegNo: Unsupported platform!\r\nCallStack (from ImplicitParams):\r\n error, called at compiler/nativeGen/Dwarf/Constants.hs:224:19 in ghc:Dwarf.Constants\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nProvide DWARF constants for registers.","type_of_failure":"OtherFailure","blocking":[]} -->⊥Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/12397Support for PDB debug information generation2019-07-07T18:26:47ZvarosiSupport for PDB debug information generationIt would be great if GHC support PDB files for debugging. This will help in Windows debugging and it will gain more stronger positions on Windows platform. There are great Windows tools for profiling and debugging that are sitting on PDB...It would be great if GHC support PDB files for debugging. This will help in Windows debugging and it will gain more stronger positions on Windows platform. There are great Windows tools for profiling and debugging that are sitting on PDB files.
Here I found format description. I'm not sure if it is similar to DWARF so it could be easily generated from existing DWARF implementation.
https://github.com/Microsoft/microsoft-pdbhttps://gitlab.haskell.org/ghc/ghc/-/issues/12642reports incorrect target arch on mips64el2019-07-07T18:25:43Zclintreports incorrect target arch on mips64elPlease handle "mips64el" in GHC_CONVERT_CPU and FPTOOLS_SET_HASKELL_PLATFORM_VARS. Having "ArchMipseb" show up in ghc --info output is confusing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---...Please handle "mips64el" in GHC_CONVERT_CPU and FPTOOLS_SET_HASKELL_PLATFORM_VARS. Having "ArchMipseb" show up in ghc --info output is confusing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"reports incorrect target arch on mips64el","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Please handle \"mips64el\" in GHC_CONVERT_CPU and FPTOOLS_SET_HASKELL_PLATFORM_VARS. Having \"ArchMipseb\" show up in ghc --info output is confusing.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12948Implement unwind rules for non-Intel architectures2020-04-23T18:04:48ZBen GamariImplement unwind rules for non-Intel architecturesTo support DWARF-based stack unwinding, a platform needs a few things,
- Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`)
- Support in the native code generator (by implementing the `generateUnwindTable` field...To support DWARF-based stack unwinding, a platform needs a few things,
- Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`)
- Support in the native code generator (by implementing the `generateUnwindTable` field of `NcgImpl`)
- A mapping of register numbers to DWARF register numbers (see `dwarfRegNo` in `nativeGhc/Dwarf/Constants.hs`)
- For unwinding support in the runtime system:
- Unwinding support in `libdw`
- a `set_initial_registers` implementation (see `rts/Libdw.c`)
Currently the only platforms that has all of these implemented is x86_64 and i386. Someone should pick up the other platforms.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement unwind rules for non-Intel architectures","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"To support DWARF-based stack unwinding, a platform needs a few things,\r\n\r\n * Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`)\r\n * Support in the native code generator (by implementing the `generateUnwindTable` field of `NcgImpl`)\r\n * A mapping of register numbers to DWARF register numbers (see `dwarfRegNo` in `nativeGhc/Dwarf/Constants.hs`)\r\n * For unwinding support in the runtime system:\r\n * Unwinding support in `libdw`\r\n * a `set_initial_registers` implementation (see `rts/Libdw.c`)\r\n\r\nCurrently the only platforms that has all of these implemented is x86_64 and i386. Someone should pick up the other platforms.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13402GHC .prof tabular output glues columns together2019-07-07T18:22:02ZdredozubovGHC .prof tabular output glues columns togetherAfter profiling an application i can see output like this:
```
mkFareSegment ...After profiling an application i can see output like this:
```
mkFareSegment Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150 88315 0.1 0.0 0.2 0.1
```
Columns are glued together in this particular part: `Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150`
It seems that the issue occurs when the fully qualified name is too long.https://gitlab.haskell.org/ghc/ghc/-/issues/13492-p option report much less time than actual on high intensity of FFI calls ap...2023-11-06T12:10:46Zvarosi-p option report much less time than actual on high intensity of FFI calls applicationProprietary application is ran on 44 cores (88 with HT) machine (same problem on 12 core). It is Haskell between wxHaskell (wxWidgets for UI) and C API. It is doing FFI calls most of the time. Calls are not so many, but possibly not so f...Proprietary application is ran on 44 cores (88 with HT) machine (same problem on 12 core). It is Haskell between wxHaskell (wxWidgets for UI) and C API. It is doing FFI calls most of the time. Calls are not so many, but possibly not so fast. I'm trying to profile where is the problem, in which calls. But very strange behaviour is there. "total time" of application that is running 30secs to 1min is showing 0.33secs. Even MAIN function is not 100%.
Please, see first part of .prof file:
```
Tue Mar 28 15:38 2017 Time and Allocation Profiling Report (Final)
app.exe +RTS -N -A40m -qb0 -p -RTS
total time = 0.33 secs (325 ticks @ 1000 us, 1 processor)
total alloc = 86,317,264 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc
MAIN MAIN <built-in> 12.6 2.2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-p option report much less time than actual on high intensity of FFI calls application","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Proprietary application is ran on 44 cores (88 with HT) machine (same problem on 12 core). It is Haskell between wxHaskell (wxWidgets for UI) and C API. It is doing FFI calls most of the time. Calls are not so many, but possibly not so fast. I'm trying to profile where is the problem, in which calls. But very strange behaviour is there. \"total time\" of application that is running 30secs to 1min is showing 0.33secs. Even MAIN function is not 100%.\r\n\r\nPlease, see first part of .prof file:\r\n\r\n\tTue Mar 28 15:38 2017 Time and Allocation Profiling Report (Final)\r\n\r\n\t app.exe +RTS -N -A40m -qb0 -p -RTS\r\n\r\n\ttotal time = 0.33 secs (325 ticks @ 1000 us, 1 processor)\r\n\ttotal alloc = 86,317,264 bytes (excludes profiling overheads)\r\n\r\nCOST CENTRE MODULE SRC %time %alloc\r\n\r\nMAIN MAIN <built-in> 12.6 2.2\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14219Include source location information in -ddump-rule-rewrites2019-07-07T18:17:53ZharendraInclude source location information in -ddump-rule-rewritesInlining is one of the most common and powerful optimizations and it interacts with rewrite-rules which is also common the libraries including base. When debugging a performance problem we are interacting with the rewrite-rules written b...Inlining is one of the most common and powerful optimizations and it interacts with rewrite-rules which is also common the libraries including base. When debugging a performance problem we are interacting with the rewrite-rules written by others hidden somewhere in some library that we are using. When I use the `-ddump-rule-rewrites` option I get an output like this:
```
Rule fired
Rule: Class op >>=
Module: (BUILTIN)
Before: GHC.Base.>>= TyArg GHC.Types.IO ValArg GHC.Base.$fMonadIO
After: GHC.Base.$fMonadIO1
```
This does not say where exactly this rule is defined in the source. It is sort of ok if this is my code I would perhaps know where this rule is. But when it is in some dependency that I am using it is hard to find.
It will be really helpful if the source location information can be provided in this dump information, so that one can go and examine the source.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.2.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Include source location information in -ddump-rule-rewrites","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Inlining is one of the most common and powerful optimizations and it interacts with rewrite-rules which is also common the libraries including base. When debugging a performance problem we are interacting with the rewrite-rules written by others hidden somewhere in some library that we are using. When I use the `-ddump-rule-rewrites` option I get an output like this:\r\n\r\n{{{\r\nRule fired\r\n Rule: Class op >>=\r\n Module: (BUILTIN)\r\n Before: GHC.Base.>>= TyArg GHC.Types.IO ValArg GHC.Base.$fMonadIO\r\n After: GHC.Base.$fMonadIO1\r\n}}}\r\n\r\nThis does not say where exactly this rule is defined in the source. It is sort of ok if this is my code I would perhaps know where this rule is. But when it is in some dependency that I am using it is hard to find.\r\n\r\nIt will be really helpful if the source location information can be provided in this dump information, so that one can go and examine the source.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14510GHC.ExecutionStack.showStackTrace broken2021-07-13T17:53:21ZDouglas Wilsondouglas@well-typed.comGHC.ExecutionStack.showStackTrace brokenWhen compiled with the dwarf bindist of 8.2.2 with
```
ghc --make -g testdwarf.hs
```
The following is output:
```
testdwarf: Failed to get stack frames of current process: no matching address range: Success
```
<details><summary>Tr...When compiled with the dwarf bindist of 8.2.2 with
```
ghc --make -g testdwarf.hs
```
The following is output:
```
testdwarf: Failed to get stack frames of current process: no matching address range: Success
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"GHC.ExecutionStack.showStackTrace broken","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"When compiled with the dwarf bindist of 8.2.2 with\r\n{{{\r\nghc --make -g testdwarf.hs \r\n}}}\r\nThe following is output:\r\n{{{\r\ntestdwarf: Failed to get stack frames of current process: no matching address range: Success\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14834Executable have problems with DWARF debug information2019-07-07T18:15:23ZvarosiExecutable have problems with DWARF debug informationWe're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64).
A crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster.
We used a tool cv2pdb to ...We're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64).
A crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster.
We used a tool cv2pdb to convert DWARF information into PDB, but we hit a crash with the tool - [https://github.com/rainers/cv2pdb/issues/23](https://github.com/rainers/cv2pdb/issues/23)
In response, the tool author brought us back a output of a problem in objdump tool over our executable:
```
c:\tmp\cv\crash>C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe -W crash.exe >objdump
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: There is a hole [0x682a - 0x6867] in .debug_loc section.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Executable have problems with DWARF debug information","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64). \r\nA crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster. \r\nWe used a tool cv2pdb to convert DWARF information into PDB, but we hit a crash with the tool - [https://github.com/rainers/cv2pdb/issues/23]\r\nIn response, the tool author brought us back a output of a problem in objdump tool over our executable:\r\n\r\n{{{\r\nc:\\tmp\\cv\\crash>C:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe -W crash.exe >objdump\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: There is a hole [0x682a - 0x6867] in .debug_loc section.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15000Add a linter for debug information (-g)2019-07-07T18:14:44ZniteriaAdd a linter for debug information (-g)There are some sanity checks we can do.
For example if you see the following Cmm:
```
unwind Sp = Just Sp + 16;
Sp = Sp + 16;
unwind Sp = Just Sp + 64;
```
You can tell that it's wrong because it's clear how `Sp` changed between the t...There are some sanity checks we can do.
For example if you see the following Cmm:
```
unwind Sp = Just Sp + 16;
Sp = Sp + 16;
unwind Sp = Just Sp + 64;
```
You can tell that it's wrong because it's clear how `Sp` changed between the two unwind points.
I think this would fit well with the Cmm linter.niterianiteriahttps://gitlab.haskell.org/ghc/ghc/-/issues/15117Add linting checks for DWARF unwind information2020-01-23T19:20:40ZBen GamariAdd linting checks for DWARF unwind informationDWARF unwind information is rather subtle and needs to be manually specified in some cases. Having at least some basic sanity checks would hep prevent against things like #14999.
<details><summary>Trac metadata</summary>
| Trac field ...DWARF unwind information is rather subtle and needs to be manually specified in some cases. Having at least some basic sanity checks would hep prevent against things like #14999.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | niteria |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add linting checks for DWARF unwind information","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["niteria"],"type":"Bug","description":"DWARF unwind information is rather subtle and needs to be manually specified in some cases. Having at least some basic sanity checks would hep prevent against things like #14999.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15179Unwinding info for stg_ap_v_info is wrong2019-07-07T18:13:54ZniteriaUnwinding info for stg_ap_v_info is wrongThe `readelf --debug-dump=frames-interp` output for `stg_ap_v_info` is:
```
00000018 0000000000000034 00000000 FDE cie=00000000 pc=000000000000000f..000000000000021d
LOC CFA rbp rsp ra
000000000000000f rbp+0 v+0...The `readelf --debug-dump=frames-interp` output for `stg_ap_v_info` is:
```
00000018 0000000000000034 00000000 FDE cie=00000000 pc=000000000000000f..000000000000021d
LOC CFA rbp rsp ra
000000000000000f rbp+0 v+0 u c+0
0000000000000037 rbp+0 v+0 vexp c+0
0000000000000047 rbp+0 v+0 s c+0
```
It's wrong because it unwinds to the same frame, see `cfa = rbp + 0`.
I know the reason, I will put it in the comments below.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unwinding info for stg_ap_v_info is wrong","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","simonmar"],"type":"Bug","description":"The `readelf --debug-dump=frames-interp` output for `stg_ap_v_info` is:\r\n\r\n{{{\r\n00000018 0000000000000034 00000000 FDE cie=00000000 pc=000000000000000f..000000000000021d\r\n LOC CFA rbp rsp ra\r\n000000000000000f rbp+0 v+0 u c+0\r\n0000000000000037 rbp+0 v+0 vexp c+0\r\n0000000000000047 rbp+0 v+0 s c+0\r\n}}}\r\n\r\nIt's wrong because it unwinds to the same frame, see `cfa = rbp + 0`.\r\n\r\nI know the reason, I will put it in the comments below.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15501Fix unknown symbols/addresses in perf output2019-07-07T18:04:28ZLast GFix unknown symbols/addresses in perf outputAfter 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 symboli...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.Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/15832fprintCCS_stderr (+RTS -xc) should be able to traverse into stacks that evalu...2023-10-20T10:15:57Zinfinity0fprintCCS_stderr (+RTS -xc) should be able to traverse into stacks that evaluated a given stack even if the latter does not come from a CAFTested in GHC 8.2.2, 8.4.3 and 8.6.1:
Test-good.hs
```hs
import GHC.Base
data X = X Int deriving (Eq, Show)
main :: IO ()
main = (returnIO undefined) `bindIO` (const (print $ X (error "XXX")))
```
Test-bad.hs
```hs
import GHC.Base
...Tested in GHC 8.2.2, 8.4.3 and 8.6.1:
Test-good.hs
```hs
import GHC.Base
data X = X Int deriving (Eq, Show)
main :: IO ()
main = (returnIO undefined) `bindIO` (const (print $ X (error "XXX")))
```
Test-bad.hs
```hs
import GHC.Base
data X = X Int deriving (Eq, Show)
main :: IO ()
main = (returnIO undefined) `bindIO` (\_ -> (print $ X (error "XXX")))
```
build.sh
```shell
#!/bin/sh
set -e
p="${1:-stg}"
for i in good bad; do
rm -rf ghc*_* Test-$i Test-$i.dump-* Test-$i.hi Test-$i.o
ghc "-ddump-$p" -dsuppress-module-prefixes -dsuppress-uniques \
-keep-tmp-files -dumpdir . -ddump-to-file \
-fno-cse -prof -fprof-auto -fprof-auto-calls -fprof-cafs \
-dinitial-unique=0 -dunique-increment=1 \
Test-$i.hs
./Test-$i +RTS -xc || true
done
colordiff -ruw Test-*.dump-"$p" | less -R
```
Running `sh build.sh` gives the following output:
```
[1 of 1] Compiling Main ( Test-good.hs, Test-good.o )
Linking Test-good ...
*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace:
Main.main,
called from Main.main,
called from Main.main,
called from Main.main,
called from Main.main,
called from Main.CAF:main
--> evaluated by: Main.main,
called from Main.main,
called from Main.main,
called from Main.CAF:main
--> evaluated by: Main.main,
called from Main.main,
called from Main.main
Test-good: XXX
CallStack (from HasCallStack):
error, called at Test-good.hs:6:57 in main:Main
CallStack (from -prof):
Main.main (Test-good.hs:6:57-67)
Main.main (Test-good.hs:6:54-68)
Main.main (Test-good.hs:6:46-68)
Main.main (Test-good.hs:6:39-69)
Main.main (Test-good.hs:6:8-70)
Main.CAF:main (Test-good.hs:6:1-4)
[1 of 1] Compiling Main ( Test-bad.hs, Test-bad.o )
Linking Test-bad ...
*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace:
Main.main,
called from Main.main,
called from Main.main,
called from Main.main
Test-bad: XXX
CallStack (from HasCallStack):
error, called at Test-bad.hs:6:57 in main:Main
CallStack (from -prof):
Main.main (Test-bad.hs:6:57-67)
Main.main (Test-bad.hs:6:54-68)
Main.main (Test-bad.hs:6:46-68)
Main.main (Test-bad.hs:6:8-70)
```
As you can see, in Test-bad.hs all the entries below "evaluated by" are missing.
I am not familiar with STG output, but running the script also shows you a diff of the STG dump. It seems innocent enough. Running `sh build.sh cmm` shows many more differences.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"returnIO/bindIO destroys runtime explicit stack information in some cases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tested in GHC 8.2.2, 8.4.3 and 8.6.1:\r\n\r\nTest-good.hs\r\n{{{#!hs\r\nimport GHC.Base\r\n\r\ndata X = X Int deriving (Eq, Show)\r\n\r\nmain :: IO ()\r\nmain = (returnIO undefined) `bindIO` (const (print $ X (error \"XXX\")))\r\n}}}\r\n\r\nTest-bad.hs\r\n{{{#!hs\r\nimport GHC.Base\r\n\r\ndata X = X Int deriving (Eq, Show)\r\n\r\nmain :: IO ()\r\nmain = (returnIO undefined) `bindIO` (\\_ -> (print $ X (error \"XXX\")))\r\n}}}\r\n\r\nbuild.sh\r\n{{{#!shell\r\n#!/bin/sh\r\nset -e\r\np=\"${1:-stg}\"\r\nfor i in good bad; do\r\n rm -rf ghc*_* Test-$i Test-$i.dump-* Test-$i.hi Test-$i.o\r\n ghc \"-ddump-$p\" -dsuppress-module-prefixes -dsuppress-uniques \\\r\n -keep-tmp-files -dumpdir . -ddump-to-file \\\r\n -fno-cse -prof -fprof-auto -fprof-auto-calls -fprof-cafs \\\r\n -dinitial-unique=0 -dunique-increment=1 \\\r\n Test-$i.hs\r\n ./Test-$i +RTS -xc || true\r\ndone\r\ncolordiff -ruw Test-*.dump-\"$p\" | less -R\r\n}}}\r\n\r\nRunning `sh build.sh` gives the following output:\r\n{{{\r\n[1 of 1] Compiling Main ( Test-good.hs, Test-good.o )\r\nLinking Test-good ...\r\n*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: \r\n Main.main,\r\n called from Main.main,\r\n called from Main.main,\r\n called from Main.main,\r\n called from Main.main,\r\n called from Main.CAF:main\r\n --> evaluated by: Main.main,\r\n called from Main.main,\r\n called from Main.main,\r\n called from Main.CAF:main\r\n --> evaluated by: Main.main,\r\n called from Main.main,\r\n called from Main.main\r\nTest-good: XXX\r\nCallStack (from HasCallStack):\r\n error, called at Test-good.hs:6:57 in main:Main\r\nCallStack (from -prof):\r\n Main.main (Test-good.hs:6:57-67)\r\n Main.main (Test-good.hs:6:54-68)\r\n Main.main (Test-good.hs:6:46-68)\r\n Main.main (Test-good.hs:6:39-69)\r\n Main.main (Test-good.hs:6:8-70)\r\n Main.CAF:main (Test-good.hs:6:1-4)\r\n[1 of 1] Compiling Main ( Test-bad.hs, Test-bad.o )\r\nLinking Test-bad ...\r\n*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: \r\n Main.main,\r\n called from Main.main,\r\n called from Main.main,\r\n called from Main.main\r\nTest-bad: XXX\r\nCallStack (from HasCallStack):\r\n error, called at Test-bad.hs:6:57 in main:Main\r\nCallStack (from -prof):\r\n Main.main (Test-bad.hs:6:57-67)\r\n Main.main (Test-bad.hs:6:54-68)\r\n Main.main (Test-bad.hs:6:46-68)\r\n Main.main (Test-bad.hs:6:8-70)\r\n}}}\r\n\r\nAs you can see, in Test-bad.hs all the entries below \"evaluated by\" are missing.\r\n\r\nI am not familiar with STG output, but running the script also shows you a diff of the STG dump. It seems innocent enough. Running `sh build.sh cmm` shows many more differences.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15889ghc documentation doesn't explain difference between dwarf levels 1 2 and 32019-07-07T18:02:34ZCarter Schonwaldghc documentation doesn't explain difference between dwarf levels 1 2 and 3I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.
The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any diffe...I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.
The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc documentation doesn't explain difference between dwarf levels 1 2 and 3","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.\r\n\r\nThe docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15960Using -g causes differences in generated core.2020-01-23T19:38:54ZAndreas KlebingerUsing -g causes differences in generated core.For nofib/shootout/fannkuch-redux:
Normal results
```
> /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques | less
...
Result size of Tidy Core
= {terms: 2,747, types: 2,7...For nofib/shootout/fannkuch-redux:
Normal results
```
> /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques | less
...
Result size of Tidy Core
= {terms: 2,747, types: 2,736, coercions: 100, joins: 50/73}
...
```
```
> /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques -g | less
...
Result size of Tidy Core
= {terms: 2,654, types: 2,557, coercions: 100, joins: 38/71}
...
```
There are also structural differences in the generated code.
I've hit the issue with a tree based on head as well so likely happening there as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Using -g causes differences in generated core.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For nofib/shootout/fannkuch-redux:\r\n\r\nNormal results\r\n{{{\r\n> /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques | less\r\n...\r\nResult size of Tidy Core\r\n = {terms: 2,747, types: 2,736, coercions: 100, joins: 50/73}\r\n...\r\n}}}\r\n\r\n{{{\r\n> /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques -g | less\r\n...\r\nResult size of Tidy Core\r\n = {terms: 2,654, types: 2,557, coercions: 100, joins: 38/71}\r\n...\r\n}}}\r\n\r\nThere are also structural differences in the generated code.\r\n\r\nI've hit the issue with a tree based on head as well so likely happening there as well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16045improve dwarf support on OSX2019-07-07T18:01:52ZCarter Schonwaldimprove dwarf support on OSXcurrently
1) we dont have stack unwinding support on OSX (libDwarf is ELF format only)
2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is...currently
1) we dont have stack unwinding support on OSX (libDwarf is ELF format only)
2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is set , but not when g0 is set. that is, even if we had a macho unwinding library for use with GHC, currently we can't even unwind base if we wanted to
3) currently the stgcrun.c code for darwin/unix envs when build on OSX, can't be built with GCC, because of some mismatch in how llvm vs gcc flavored tools on osx handle dwarf. This means this file, IF we had unwinding support, would need to be built with clang (apple or llvm flavored).
3 a)HOWEVER: on OSX the threaded RTS (when built with clang) is \~15% slower than the same built with GCC.
3 b) so ideally, in a future world with unwinding on OSX, tweaking the build system to make sure that the STGCRUN.c code it always built with clang, or some other fix, that still permits a GCC built RTS OR otherwise does a fix to that GC rts perf issue, would be ideal
Theres a few different action items here, and some of them are quite messy, but they all need to be done for decent perf and debugging experiences on OSX to be in the GHC future!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"improve dwarf support on OSX","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"currently \r\n\r\n1) we dont have stack unwinding support on OSX (libDwarf is ELF format only)\r\n\r\n2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is set , but not when g0 is set. that is, even if we had a macho unwinding library for use with GHC, currently we can't even unwind base if we wanted to \r\n\r\n3) currently the stgcrun.c code for darwin/unix envs when build on OSX, can't be built with GCC, because of some mismatch in how llvm vs gcc flavored tools on osx handle dwarf. This means this file, IF we had unwinding support, would need to be built with clang (apple or llvm flavored). \r\n\r\n3 a)HOWEVER: on OSX the threaded RTS (when built with clang) is ~15% slower than the same built with GCC.\r\n\r\n3 b) so ideally, in a future world with unwinding on OSX, tweaking the build system to make sure that the STGCRUN.c code it always built with clang, or some other fix, that still permits a GCC built RTS OR otherwise does a fix to that GC rts perf issue, would be ideal\r\n\r\nTheres a few different action items here, and some of them are quite messy, but they all need to be done for decent perf and debugging experiences on OSX to be in the GHC future!","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16286Continuations are not labelled in the binaries even with -g32019-09-02T10:56:21ZÖmer Sinan AğacanContinuations are not labelled in the binaries even with -g3Any program would work as a reproducer, but here's what I'm using currently:
```
{-# LANGUAGE StaticPointers #-}
module Main where
import Control.Concurrent
import System.Mem
nats :: [Int]
nats = [0 .. ]
main = do
let z = nats !! ...Any program would work as a reproducer, but here's what I'm using currently:
```
{-# LANGUAGE StaticPointers #-}
module Main where
import Control.Concurrent
import System.Mem
nats :: [Int]
nats = [0 .. ]
main = do
let z = nats !! 400
print z
performGC
threadDelay 1000000
print (nats !! 900)
```
If I do `printStack` every time the GC copies a stack I sometimes see stack frames like
```
RET_SMALL (0x535568)
```
but in gdb or objdump output I can't find a symbol at that address, even when the program is built with `-g3`. When I print the location as `StgInfoTable*` I can see that it's a valid info table so `0x535578` should be labelled as `foo_info`.
In the objdump output I see that the location is shown as this:
```
535563: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
...
535570: 1e (bad)
535571: 00 00 add %al,(%rax)
535573: 00 00 add %al,(%rax)
535575: 00 00 add %al,(%rax)
535577: 00 bb e9 e2 85 00 add %bh,0x85e2e9(%rbx)
53557d: 48 83 c5 08 add $0x8,%rbp
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Continuations are not labelled in the binaries even with -g3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Any program would work as a reproducer, but here's what I'm using currently:\r\n\r\n{{{\r\n{-# LANGUAGE StaticPointers #-}\r\n\r\nmodule Main where\r\n\r\nimport Control.Concurrent\r\nimport System.Mem\r\n\r\nnats :: [Int]\r\nnats = [0 .. ]\r\n\r\nmain = do\r\n let z = nats !! 400\r\n print z\r\n performGC\r\n threadDelay 1000000\r\n print (nats !! 900)\r\n}}}\r\n\r\nIf I do `printStack` every time the GC copies a stack I sometimes see stack frames like\r\n\r\n{{{\r\nRET_SMALL (0x535568)\r\n}}}\r\n\r\nbut in gdb or objdump output I can't find a symbol at that address, even when the program is built with `-g3`. When I print the location as `StgInfoTable*` I can see that it's a valid info table so `0x535578` should be labelled as `foo_info`. \r\n\r\nIn the objdump output I see that the location is shown as this:\r\n\r\n{{{\r\n 535563:\t0f 1f 44 00 00 \tnopl 0x0(%rax,%rax,1)\r\n\t...\r\n 535570:\t1e \t(bad) \r\n 535571:\t00 00 \tadd %al,(%rax)\r\n 535573:\t00 00 \tadd %al,(%rax)\r\n 535575:\t00 00 \tadd %al,(%rax)\r\n 535577:\t00 bb e9 e2 85 00 \tadd %bh,0x85e2e9(%rbx)\r\n 53557d:\t48 83 c5 08 \tadd $0x8,%rbp\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->