September 2018 - ghc-tickets

[GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls
by GHC 03 Mar '19

03 Mar '19

#11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Unsafe foreign calls result in adjustments to `$rsp` made in the NCG to comply with calling convention alignment requirements (see `X86.CodeGen.genCCall64'`). Unfortunately, this happens after we've generated unwind information. This results in incorrect unwinding information for `$rsp` when inside of a foreign call. The results can be quite catastrophic (e.g. segmentation faults while unwinding). Unfortunately it's really not clear what can be done about this given that these adjustments aren't present in the Cmm representation that we use to produce frame information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12397: Support for PDB debug information generation
by GHC 03 Mar '19

03 Mar '19

#12397: Support for PDB debug information generation -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Debugging) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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. 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-pdb -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12948: Implement unwind rules for non-Intel architectures
by GHC 03 Mar '19

03 Mar '19

#12948: Implement unwind rules for non-Intel architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12948> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13866: -g doesn't work with -pgma=clang++
by GHC 03 Mar '19

03 Mar '19

#13866: -g doesn't work with -pgma=clang++ -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a follow-up to #11202. The fix there is platform specific, but the problem is compiler/assembler specific. Sample of errors: {{{ /tmp/ghc4044980_0/ghc_2.s:681:2: error: error: unknown directive .hword 4 ^ | 681 | .hword 4 | ^ }}} Repro command: {{{ $ cat A.hs module A where main = putStrLn "Hello" $ ./inplace/bin/ghc-stage2 -g -pgma=clang++ A.hs }}} One workaround that I've found: {{{ $ ./inplace/bin/ghc-stage2 -g -pgma=clang++ -opta=-no-integrated-as A.hs # succeeds }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14221: yaml-0.8.23.3 fails to build with -g
by GHC 03 Mar '19

03 Mar '19

#14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `yaml-0.8.23.3` fails to build with an assembler error, {{{ $ cabal unpack yaml-0.8.23.3 $ ghc Data/Yaml/Internal.hs -O -g [1 of 2] Compiling Text.Libyaml ( Text/Libyaml.hs, Text/Libyaml.o ) [Data.Conduit changed] [2 of 2] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, Data/Yaml/Internal.o ) /tmp/ghc17780_0/ghc_9.s: Assembler messages: /tmp/ghc17780_0/ghc_9.s:64575:0: error: Error: can't resolve `.LcJO0_entry_end' {*UND* section} - `cJO0_entry' {*UND* section} | 64575 | .quad .LcJO0_entry_end-cJO0_entry | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) }}} Strangely enough, the symbols `.LcJO0` and `.LcJO0_end` are defined in the resulting assembler, but not `.LcJO0_entry_end` nor `cJO0_entry`. I suspect the backend -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14510: GHC.ExecutionStack.showStackTrace broken
by GHC 03 Mar '19

03 Mar '19

#14510: GHC.ExecutionStack.showStackTrace broken -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14999: unwinding info for stg_catch_frame is wrong
by GHC 03 Mar '19

03 Mar '19

#14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimized `stg_catch_frame` (`Small.cmm`): {{{ #define CATCH_FRAME 34 #define SIZEOF_StgCatchFrame (SIZEOF_StgHeader+16) INFO_TABLE_RET(stg_catch_frame, CATCH_FRAME, bits64 info_ptr, bits64 exceptions_blocked, gcptr handler) return (gcptr ret) { unwind Sp = Sp + SIZEOF_StgCatchFrame; return (ret); } }}} Compile `"inplace/bin/ghc-stage2" -O2 -g -c Small.cmm` using GHC HEAD. `objdump -D` for `stg_catch_frame_info`: {{{ 0000000000000010 <stg_catch_frame_info>: 10: 48 83 c5 18 add $0x18,%rbp 14: ff 65 00 jmpq *0x0(%rbp) }}} `readelf --debug-dump=frames-interp Small.o`: {{{ Contents of the .debug_frame section: 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra 0000000000000000 rbp+0 v+0 s c+0 00000018 000000000000002c 00000000 FDE cie=00000000 pc=000000000000000f..0000000000000017 LOC CFA rbp rsp ra 000000000000000f rbp+0 v+0 s c+0 000000000000000f rbp+24 v+0 s c+0 0000000000000010 rbp+0 v+0 s c+0 }}} **How do I know this is wrong?** http://www.dwarfstd.org/doc/dwarf-2.0.0.pdf has a nice example in Appendix 5 (page 101 of the pdf). The question that I had was if the CFA value at LOC is after or before the instruction at LOC executes. Appendix 5 clearly shows that it's **before**. Hence for LOC = 0x10 here CFA shouldn't have changed. It can and should change at LOC = 0x14. For comparison this is what `8.0.2` produced (and it worked more often): {{{ 0000000000000010 <stg_catch_frame_info>: 10: 48 83 c5 18 add $0x18,%rbp 14: ff 65 00 jmpq *0x0(%rbp) }}} {{{ Contents of the .debug_frame section: 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra 0000000000000000 rbp+0 v+0 s c+0 00000018 0000000000000024 00000000 FDE cie=00000000 pc=000000000000000f..0000000000000017 LOC CFA rbp rsp ra 000000000000000f rbp+0 v+0 s c+0 000000000000000f rbp+24 v+0 s c+0 }}} Debugging follows in the comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14894: HEAD fails to build with -g1
by GHC 03 Mar '19

03 Mar '19

#14894: HEAD fails to build with -g1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I wanted to see how `-g1` vs `-g2` impact compile speed. Unfortunately I get linking errors trying to build GHC with `-g`. Steps: 1) Add {{{ GhcLibHcOpts += -g1 GhcRtsHcOpts += -g1 }}} to `mk/build.mk`. I used devel2 flavor. 2) `./boot && ./configure && make -j` 3) Observe failure The failure (trimmed): {{{ /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1c94): error: undefined refe rence to '.LcbG2_info_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1cc7): error: undefined refe rence to '.LcbGL_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1cfa): error: undefined refe rence to '.LcbI0_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1d2d): error: undefined refe rence to '.LcbIh_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x21a4): error: undefined refe rence to '.LcbSn_info_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x21d1): error: undefined refe rence to '.LcbTc_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x234f): error: undefined refe rence to '.Lcc18_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2c76): error: undefined refe rence to '.Lccmj_info_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2dff): error: undefined refe rence to '.LccsV_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2e2f): error: undefined refe rence to '.Lcct6_info_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2f38): error: undefined refe rence to '.Lccv1_info_die' /data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist- install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2f66): error: undefined refe rence to '.Lccve_die' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14834: Executable have problems with DWARF debug information
by GHC 03 Mar '19

03 Mar '19

#14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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] 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. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15117: Add linting checks for DWARF unwind information
by GHC 03 Mar '19

03 Mar '19

#15117: Add linting checks for DWARF unwind information -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5