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":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/17609DWARF DIEs are extremely verbose2021-10-07T16:33:57ZBen GamariDWARF DIEs are extremely verboseThe DIEs produced by GHC are much larger than necessary.
```
.L$wadvance_r4Sp_info_die:
.byte 2
.asciz "advance"
.asciz "r4Sp_info" ...The DIEs produced by GHC are much larger than necessary.
```
.L$wadvance_r4Sp_info_die:
.byte 2
.asciz "advance"
.asciz "r4Sp_info"
.byte 0
.quad $wadvance_r4Sp_info
.quad .L$wadvance_r4Sp_info_end
.byte 1
.byte 156
.Lc55F_die:
.byte 5
.asciz "_c55F"
.quad _c55F
.quad .Lc55F_end
.byte 6
.asciz "nofib/shootout/n-body/Main.hs"
.long 64
.short 1
.long 88
.short 19
.byte 6
.asciz "nofib/shootout/n-body/Main.hs"
.long 88
.short 12
.long 88
.short 19
.byte 6
.asciz "nofib/shootout/n-body/Main.hs"
.long 136
.short 1
.long 136
.short 17
.byte 6
.asciz "nofib/shootout/n-body/Main.hs"
.long 142
.short 1
.long 142
.short 32
.byte 6
```
Specifically, the source filename string is repeated for every DIE. I'm pretty sure there is a way to encode this rather into the debug strings section.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17627stg_PAP_apply doesn't unwind correctly2019-12-31T02:11:00ZBen Gamaristg_PAP_apply doesn't unwind correctlyThe unwind information on `stg_PAP_apply` is incorrect. Specifically, we can't currently generate unwinding information for the dynamic `Sp` adjustment performed therein.The unwind information on `stg_PAP_apply` is incorrect. Specifically, we can't currently generate unwinding information for the dynamic `Sp` adjustment performed therein.https://gitlab.haskell.org/ghc/ghc/-/issues/20015Worker Wrapper should duplicate source notes onto the wrapper2021-12-24T21:32:03ZMatthew PickeringWorker Wrapper should duplicate source notes onto the wrapperSuppose you have a definition
```
toIfaceTyCon :: TyCon -> IfaceTyCon
```
then if you compile with `-g3` to enable source notes then the desugared version might look like
```
toIfaceTyCon = \w -> <tick> body
```
Worker wrapper then ...Suppose you have a definition
```
toIfaceTyCon :: TyCon -> IfaceTyCon
```
then if you compile with `-g3` to enable source notes then the desugared version might look like
```
toIfaceTyCon = \w -> <tick> body
```
Worker wrapper then applies to `toIfaceTyCon`, and performs the WW split, at which point the tick is only moved into the worker.
```
$wToIfaceTyCon :: TyCon -> (# IfExtName, IfaceTyConInfo #)
$wToIfaceTyCon = \tc -> <TICK> body
toIfaceTyCon
= \ (w_saGx :: TyCon) ->
case GHC.CoreToIface.$wtoIfaceTyCon w_saGx of
{ (# ww1_saJK, ww2_saJL #) ->
GHC.Iface.Type.IfaceTyCon ww1_saJK ww2_saJL
}
```
Now there is a source of allocation, `IfaceTyCon`, which won't get a proper entry in the IPE map because there isn't a surrounding tick. It would be better if the tick was copied onto the worker as well so the allocation could be tracked back to the definition of toIfaceTyCon.
```
$wToIfaceTyCon :: TyCon -> (# IfExtName, IfaceTyConInfo #)
$wToIfaceTyCon = \tc -> <TICK> body
toIfaceTyCon
= \ (w_saGx :: TyCon) -> <TICK>
case GHC.CoreToIface.$wtoIfaceTyCon w_saGx of
{ (# ww1_saJK, ww2_saJL #) ->
GHC.Iface.Type.IfaceTyCon ww1_saJK ww2_saJL
}
```Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/20252Add Haskell specific dwarf attributes to binutils2021-08-19T18:13:54ZAndreas KlebingerAdd Haskell specific dwarf attributes to binutilsGHC has it's own tags that are also recgonized by the dwarf5 standard afaik.
However they currently only show up as "Unknown user tag" or something along these lines
when dumping dwarf info via e.g. objdump.
It would good to add support...GHC has it's own tags that are also recgonized by the dwarf5 standard afaik.
However they currently only show up as "Unknown user tag" or something along these lines
when dumping dwarf info via e.g. objdump.
It would good to add support for these to upstream binutils. But it's certainly low priority.https://gitlab.haskell.org/ghc/ghc/-/issues/20867Should we annotate evidence in HsWrapper with ticks?2022-02-09T16:23:24ZMatthew PickeringShould we annotate evidence in HsWrapper with ticks?I noticed that the coverage passes don't annotate the evidence gathered in a HsWrapper with (source note) ticks.
In practice, I am not sure how much difference this makes to anything but given we annotate normal let-bound things then i...I noticed that the coverage passes don't annotate the evidence gathered in a HsWrapper with (source note) ticks.
In practice, I am not sure how much difference this makes to anything but given we annotate normal let-bound things then it might improve IPE/DWARF info if we annotate let bound evidence as well.
cc @bgamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21407Add support for splitting debug symbols2024-02-27T13:58:43ZZubinAdd support for splitting debug symbolsCurrently we offer builds with debug/DWARF information embedded in them. Ideally these wouldn't be separate builds but just packages containing debug symbols that would be compatible with the regular distributions.
We would need to figu...Currently we offer builds with debug/DWARF information embedded in them. Ideally these wouldn't be separate builds but just packages containing debug symbols that would be compatible with the regular distributions.
We would need to figure out how to support splitting out and emitting the debug information separately while compiling code.
In the future we could also use this to offer a [debuginfod](https://wiki.debian.org/Debuginfod) server for profiling and debugging GHC/boot libraries.https://gitlab.haskell.org/ghc/ghc/-/issues/21471Source notes impact compilation results as evident by -dannot-lint failures w...2024-01-29T16:51:14ZMatthew PickeringSource notes impact compilation results as evident by -dannot-lint failures when running GHC testsuitePassing -dannot-lint to the testsuite highlights quite a few tests which fail the check.
If I run with
```
+TEST_HC_OPTS += -dannot-lint
+TEST_HC_OPTS += -finfo-table-map
```
then I get a few more failures
```
"T11068 T13367 T13585 ...Passing -dannot-lint to the testsuite highlights quite a few tests which fail the check.
If I run with
```
+TEST_HC_OPTS += -dannot-lint
+TEST_HC_OPTS += -finfo-table-map
```
then I get a few more failures
```
"T11068 T13367 T13585 T15155 T15155l T15970 T17901 T3736 T4003 T5658b T5996 cg010 determ017 determ018 str-rules"
```
Test log:
https://gist.github.com/b7df0ef343f4e856eb4eda4bf0eebc04
Also running -dannot-lint on GHC itself fails, likewise for Cabal. Really we claim that source notes don't affect the optimiser so the lint pass should work fine.
Perhaps something for @AndreasK, the tick master.https://gitlab.haskell.org/ghc/ghc/-/issues/21878Report IPE information of thunks involved in cycles2022-07-25T15:32:07ZBen GamariReport IPE information of thunks involved in cyclesCurrently debugging cyclic thunks (e.g. the `NonTermination` exception, which manifests as the dreaded `<<loop>>` message) is quite difficult. I generally have to resort to `ghc-debug` or `gdb` to understand such cases. However, with IPE...Currently debugging cyclic thunks (e.g. the `NonTermination` exception, which manifests as the dreaded `<<loop>>` message) is quite difficult. I generally have to resort to `ghc-debug` or `gdb` to understand such cases. However, with IPE information we now have the ability to determine the provenance of thunks. It would be nice if GHC could attach the set of IPE information (and perhaps cost-centers, if profiling) involved in the cycle to the `NonTermination` exception.https://gitlab.haskell.org/ghc/ghc/-/issues/21930Optionally include a measure of work size in -ddump-timings.2022-08-01T09:51:52ZAndreas KlebingerOptionally include a measure of work size in -ddump-timings.Currently -ddump-timings is quite handy to measure the time/allocations for certain phases.
However it's hard to judge if a growth in time/allocations stems from the compiler processing a larger work load or from us processing it less e...Currently -ddump-timings is quite handy to measure the time/allocations for certain phases.
However it's hard to judge if a growth in time/allocations stems from the compiler processing a larger work load or from us processing it less efficiently.
So I would like to have a flag like `-ddump-timings-extra` which produces a bit more information.
In particular instead of emitting this info:
```
Simplifier [Agda.Syntax.Parser.Lexer]: alloc=124670096 time=52.135
Simplifier [Agda.Syntax.Parser.Lexer]: alloc=122955936 time=51.450
```
I would like to include info about the core size. For example emit something like:
```
Simplifier [Agda.Syntax.Parser.Lexer]: alloc=124670096 time=52.135 size={total=50, terms=20, types=30, coercions=0}
Simplifier [Agda.Syntax.Parser.Lexer]: alloc=122955936 time=51.450 size={total=60, terms=20, types=30, coercions=10}
```
We could do so by changing withTiming to something like:
```haskell
withTiming :: MonadIO m
=> Logger
-> SDoc -- ^ The name of the phase
-> (a -> ()) -- ^ A function to force the result
-- (often either @const ()@ or 'rnf')
-> (a -> SDoc) -- ^ A function to output a representation of the size of the result (e.g. core size)
-> m a -- ^ The body of the phase to be timed
-> m a
```https://gitlab.haskell.org/ghc/ghc/-/issues/22031slow validate failure: UnliftedMutVar_Comp (hpc way)2023-09-07T10:37:31ZMatthew Pickeringslow validate failure: UnliftedMutVar_Comp (hpc way)Reproduce with
```
hadrian/build test --freeze1 --docs=none --flavour=slow-validate --test-speed=slow --only="UnliftedMutVar_Comp"
```
Looks like something needs to look through ticks or a failure in eta-expansion.
```
GHC version 9...Reproduce with
```
hadrian/build test --freeze1 --docs=none --flavour=slow-validate --test-speed=slow --only="UnliftedMutVar_Comp"
```
Looks like something needs to look through ticks or a failure in eta-expansion.
```
GHC version 9.5.20220805:
tyConAppTyCon
l_1c
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:188:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:1500:52 in ghc:GHC.Core.Type
tyConAppTyCon, called at compiler/GHC/Builtin/Types.hs:1622:35 in ghc:GHC.Builtin.Types
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
*** unexpected failure for UnliftedMutVar_Comp(hpc)
```Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/22034slow validate failure: GivenCheckSwap in hpc way2023-09-07T10:54:55ZMatthew Pickeringslow validate failure: GivenCheckSwap in hpc wayReproduce with
```
hadrian/build test --freeze1 --docs=none --flavour=slow-validate --test-speed=slow --only="GivenCheckSwap"
```
Looks like something needs to look through ticks.
```
-
-GivenCheckSwap.hs:11:9: warning: [-Woverlappin...Reproduce with
```
hadrian/build test --freeze1 --docs=none --flavour=slow-validate --test-speed=slow --only="GivenCheckSwap"
```
Looks like something needs to look through ticks.
```
-
-GivenCheckSwap.hs:11:9: warning: [-Woverlapping-patterns (in -Wdefault)]
- Pattern match is redundant
- In an equation for ‘g’: g y | False = ...
*** unexpected failure for GivenCheckSwap(hpc)
```Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22343Assembler failures in multiple tests on nightly-x86_64-linux-deb10-no_tntc-va...2023-02-15T05:17:28ZBryan Rbryan@haskell.foundationAssembler failures in multiple tests on nightly-x86_64-linux-deb10-no_tntc-validateOne example of many:
```
/tmp/ghc306691_0/ghc_1.s: Assembler messages:
/tmp/ghc306691_0/ghc_1.s:136:0: error:
Error: symbol `.Lc2oQ_end' is already defined
/tmp/ghc306691_0/ghc_1.s:137:0: error:
Error: symbol `.Lc2oQ_proc_end'...One example of many:
```
/tmp/ghc306691_0/ghc_1.s: Assembler messages:
/tmp/ghc306691_0/ghc_1.s:136:0: error:
Error: symbol `.Lc2oQ_end' is already defined
/tmp/ghc306691_0/ghc_1.s:137:0: error:
Error: symbol `.Lc2oQ_proc_end' is already defined
/tmp/ghc306691_0/ghc_1.s:241:0: error:
Error: symbol `.Lc2oE_end' is already defined
/tmp/ghc306691_0/ghc_1.s:242:0: error:
Error: symbol `.Lc2oE_proc_end' is already defined
/tmp/ghc306691_0/ghc_1.s:357:0: error:
Error: symbol `.Lc2or_end' is already defined
/tmp/ghc306691_0/ghc_1.s:358:0: error:
Error: symbol `.Lc2or_proc_end' is already defined
<no location info>: error:
`gcc' failed in phase `Assembler'. (Exit code: 1)
*** unexpected failure for T14894(optasm)
```
Job [#1210736](https://gitlab.haskell.org/ghc/ghc/-/jobs/1210736) failed for 8d2dbe2db4cc7c8b6d39b1ea64b0508304a3273c:Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22501-dsuppress-uniques suppresses C-- labels2023-02-21T16:59:34ZJaro Reinders-dsuppress-uniques suppresses C-- labels## Summary
When using `-ddump-cmm -dsuppress-uniques` I get code like this:
```
_lbl_: // global
__locVar_::P64 = R2;
if ((Sp + -24) >= SpLim) (likely: True) goto c1Bp; else goto c1BA;
_lbl_: // glob...## Summary
When using `-ddump-cmm -dsuppress-uniques` I get code like this:
```
_lbl_: // global
__locVar_::P64 = R2;
if ((Sp + -24) >= SpLim) (likely: True) goto c1Bp; else goto c1BA;
_lbl_: // global
I64[Sp - 8] = c1Bs;
R1 = __locVar_::P64;
Sp = Sp - 8;
if (R1 & 7 != 0) goto c1Bs; else goto c1Bt;
```
As you can see there are still label names in the gotos like `goto c1Bp`, but all the labels have been renamed to `_lbl_`.
I think the most useful behavior would be to keep showing the actual label names. Alternatively you could resolve this inconsistency by also replacing all gotos by `goto _lbl_`, but that wouldn't be very useful.
## Environment
* GHC version used: 9.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/22636[question] Why do `-g` and `-fhpc` generate different `CoreTickish`es?2022-12-20T15:40:18ZZiyang Liuunsafefixio@gmail.com[question] Why do `-g` and `-fhpc` generate different `CoreTickish`es?As far as I can tell, the `TickDensity` of both `-g` and `-fhpc` is `TickForCoverage`, so I'd expect both to generate the same `CoreTickish`es. However, it is not the case:
```haskell
{-# LANGUAGE ScopedTypeVariables #-}
{-# OPTIONS_GHC...As far as I can tell, the `TickDensity` of both `-g` and `-fhpc` is `TickForCoverage`, so I'd expect both to generate the same `CoreTickish`es. However, it is not the case:
```haskell
{-# LANGUAGE ScopedTypeVariables #-}
{-# OPTIONS_GHC -fmax-simplifier-iterations=0 #-}
{-# OPTIONS_GHC -ddump-simpl #-}
{-# OPTIONS_GHC -O0 #-}
module A where
f = \(x :: Bool) (y :: Bool) -> x == y
```
From `ghc -c -g A.hs`:
```
f = \ (ds_dG9 :: Bool) (ds1_dGa :: Bool) ->
src<A.hs:8:1-38>
==
@Bool
GHC.Classes.$fEqBool
(src<A.hs:8:33> ds_dG9)
(src<A.hs:8:38> ds1_dGa)
```
From `ghc -c -fhpc A.hs`:
```
f = hpc<A,4>
hpc<A,3>
\ (ds_dG9 :: Bool) (ds1_dGa :: Bool) ->
hpc<A,2>
== @Bool GHC.Classes.$fEqBool (hpc<A,0> ds_dG9) (hpc<A,1> ds1_dGa)
```
There are two differences:
1. `-g` did not create Ticks on the Lambda.
2. The source spans on `== @Bool ...` are different. `-g` gave `8:1-38`, while `-fhpc` gave `8:33-38` (i.e., `x == y`).
Why the differences? The reason I'm asking is because the source spans I get from `-fhpc` are more useful to me, but `-g` is much more convenient.https://gitlab.haskell.org/ghc/ghc/-/issues/23078Objects loaded via the RTS linker do not expose symbols to GDB2023-03-09T23:25:38ZAlexis KingObjects loaded via the RTS linker do not expose symbols to GDBWhen the RTS linker is used to load objects and archives, any debugging information produced by `-g` is necessarily invisible to GDB. Loading the symbols from the archive manually does not help because only GHC knows the address the obje...When the RTS linker is used to load objects and archives, any debugging information produced by `-g` is necessarily invisible to GDB. Loading the symbols from the archive manually does not help because only GHC knows the address the objects are ultimately loaded at.
It seems possible to dynamically expose these symbols to GDB using its [JIT interface](https://sourceware.org/gdb/download/onlinedocs/gdb/JIT-Interface.html). However, I am not sure how difficult this would be to use in practice, as I don’t currently understand the way the RTS linker works.
On platforms where `ghc` is dynamically linked by default (which I believe is everywhere except Windows), this is probably not a big deal, since GHC just uses `dlopen` on those platforms. Since `-g` is currently only supported on Linux, this doesn’t seem like a particularly big problem. However, when *developing* GHC, I am often using a statically-linked GHC, and sometimes I even run into cases where I can only trigger a bug with GHC statically linked. (Such a case is what prompted me to open this issue.) So it would be very nice to be able to have debugging symbols in that configuration.https://gitlab.haskell.org/ghc/ghc/-/issues/23680aarch64 build failure related to dwarf unwinding2023-07-25T14:01:40ZCheng Shaoaarch64 build failure related to dwarf unwindingWhen I'm building a recent revision of GHC using ghc.nix on my aarch64 nixos server, I noticed the following build failure:
```
Command line: /nix/store/cjp67pyjk691vgwzv6n05gb3kxbc38qv-gcc-wrapper-12.2.0/bin/cc -E -MM -MG -MF _build/st...When I'm building a recent revision of GHC using ghc.nix on my aarch64 nixos server, I noticed the following build failure:
```
Command line: /nix/store/cjp67pyjk691vgwzv6n05gb3kxbc38qv-gcc-wrapper-12.2.0/bin/cc -E -MM -MG -MF _build/stage1/rts/build/c/Libdw.o.d -MT _build/stage1/rts/build/c/Libdw.o -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -I/nix/store/qrvf48kb00j3nakxp6m9avwcq2kxjzyl-elfutils-0.189-dev/include -I/nix/store/qgxqk77h55yg4s6dp668s770074xm5vj-numactl-2.0.16/include -Irts/include -I/nix/store/qrvf48kb00j3nakxp6m9avwcq2kxjzyl-elfutils-0.189-dev/include -I/nix/store/qgxqk77h55yg4s6dp668s770074xm5vj-numactl-2.0.16/include -x c rts/Libdw.c -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -fomit-frame-pointer -O2 -Irts -I_build/stage1/rts/build
===> Command failed with error code: 1
rts/Libdw.c:369:6: error: #error "Please implement set_initial_registers() for your arch"
369 | # error "Please implement set_initial_registers() for your arch"
| ^~~~~
Command failed
Build failed.
```
Setting `withDwarf = false` in `ghc.nix` is sufficient to get the build going, so I assume dwarf unwinding is not working with aarch64 yet. Should we do something about it in the `configure` step? It would be nice if this build-time failure can be caught at configure time.9.10.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24514Emit DWARFv52024-03-12T14:57:35ZSophie TaylorEmit DWARFv5The GHC manual states that GHC emits DWARFv4 information. [DWARFv5](https://dwarfstd.org/dwarf5std.html), stabilised in 2017, includes several new features relevant to Haskell:
- Haskell language code
- A new DIE, `DW_TAG_call_site`, and...The GHC manual states that GHC emits DWARFv4 information. [DWARFv5](https://dwarfstd.org/dwarf5std.html), stabilised in 2017, includes several new features relevant to Haskell:
- Haskell language code
- A new DIE, `DW_TAG_call_site`, and related attributes and expressions, which can include tail call and tail recursion information
- A new attribute, `DW_AT_noreturn`, which would be useful for CPS'd code
There is some minor incompatibility between DWARFv4 and DWARFv5, but it's probably worth the effort to greatly increase the quality of the debug information. For starters, it seems that the `DW_TAG_call_site` information could be emitted without having to make the migration changes.
An example of `gdb` support for this is here: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Tail-Call-Frames.html