August 2018 - ghc-tickets

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

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler)
by GHC 04 Mar '19

04 Mar '19

#15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) ----------------------------------------+--------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- for current master, if i build on a mac / OSX high sierra environment with CC set as any flavor of recent GCC rather than apple clang, i get a failure "no open frame" when as (aka apple clang / apple llvm acting as the assembler) is run on the .s file produced by stgRun.c (rts/StgCRun.c to be exact) this error message seems to come from https://github.com/llvm- mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has the gcc and clang style assembly for /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o rts/dist/build/StgCRun.debug_o this is example asm for the the debug way -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 49