February 2019 - ghc-tickets

[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

[GHC] #15179: Unwinding info for stg_ap_v_info is wrong
by GHC 03 Mar '19

03 Mar '19

#15179: Unwinding info for stg_ap_v_info is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Debugging) | Keywords: | Operating System: Linux Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3
by GHC 03 Mar '19

03 Mar '19

#15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Documentation | Version: 8.6.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: -------------------------------------+------------------------------------- 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?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15889> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2