August 2017 - ghc-tickets

[GHC] #10915: Statistical profiling support in the RTS
by GHC 03 Mar '19

03 Mar '19

#10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1215, | Phab:D1214 | -------------------------------------+------------------------------------- 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. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11261: Implement DWARF debugging on powerpc64
by GHC 03 Mar '19

03 Mar '19

#11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: debug, T10667 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11337: Unwind information incorrect between Sp adjustment and end of block
by GHC 03 Mar '19

03 Mar '19

#11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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: -------------------------------------+------------------------------------- As pointed out in Phab:D1532, the DWARF unwinding information that we produce is currently a bit oversimplified. Namely, we produce exactly one unwind table per Cmm block. This works reasonably well in most cases since we most Cmm blocks have the form, {{{ aProcedure() { casl: -- we just entered the procedure, so the unwinding is trivial. unwind Sp = Sp -- we push some values onto the stack... I64[Sp - 16] = ... I64[Sp - 8] = ... -- and before leaving the block we update Sp. Sp = Sp - 16; -- technically our unwind information is now a lie call aFunction() returns to casd; casd: -- we inherit the unwind information from the state of the stack when we -- left the preceding block (casl) unwind Sp = Sp + 16 R2 = I64[Sp + 8]; -- pop off that which we pushed Sp = Sp + 16; call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; }}} Here there is a narrow window where our unwind information is technically wrong: between updating `Sp` in `casl` and calling into `aFunction`. Note that after we arrive in `aFunction` we are safe, since our return address is `casd`, which has the correct unwinding information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11338: Unwind information is incorrect in region surrounding a safe foreign call
by GHC 03 Mar '19

03 Mar '19

#11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11337 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Safe foreign calls can occur at the end of a block. Like #11337, these produce incorrect debug information. However, the situation is worse in the case of foreign calls since these return to the calling block. This means that we are currently unable to unwind out of a safe foreign call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #10841: Run handler on STM retry
by GHC 03 Mar '19

03 Mar '19

#10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be nice to have a function like: {{{#!hs -- | Perform a series of STM actions atomically. -- -- Whenever the transaction retries, run the handler. If it doesn't return 'Nothing', -- stop the retrying and return the value given by the handler. atomicallyWithRetryHandler :: STM a -> IO (Maybe a) -> IO a }}} This would allow tracking retry statistics, printing debug messages on each retry, etc. without resorting to unsafeIOToSTM which can't safely do things like printing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13002: :set -O does not work in .ghci file
by GHC 03 Mar '19

03 Mar '19

#13002: :set -O does not work in .ghci file --------------------------------------+---------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround that isn't feasible as far as I know when using emacs thus setting priority to normal rather than low. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19