March 2019 - ghc-tickets

[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

[GHC] #16045: improve dwarf support on OSX
by GHC 03 Mar '19

03 Mar '19

#16045: improve dwarf support on OSX --------------------------------------+--------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- 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! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4