September 2013 - ghc-tickets

Re: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols
by GHC 06 Sep '13

06 Sep '13

#2841: Ghci + foreign export declarations result in undefined symbols -----------------------------------+------------------------------------ Reporter: fasta | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by ezyang): * status: new => closed * resolution: => worksforme * blocking: 8199 => Comment: Actually, looking at the original bug here, it seems unrelated to the patchset I'm working on, and #5435 seems to be the right place to hang these patches. I can't reproduce the original symbol error, so I'm going to close this worksforme. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2841#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8237: checkProddableBlock: invalid fixup in runtime linker (Windows)
by GHC 06 Sep '13

06 Sep '13

#8237: checkProddableBlock: invalid fixup in runtime linker (Windows) ----------------------------------+--------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I attempted to load a very simple C file into GHC using the linker and got this error. The C file is: {{{ #include <stdio.h> static void f(void); // __attribute__((constructor)); static void f(void) { printf("Hooray!"); } }}} and the test program: {{{ {-# LANGUAGE ForeignFunctionInterface #-} import Foreign.C.String main = do initLinker withCWString "test.o" $ \s -> loadObj s resolveObjs foreign import ccall "initLinker" initLinker :: IO () foreign import ccall "loadObj" loadObj :: CWString -> IO Int foreign import ccall "resolveObjs" resolveObjs :: IO () }}} Test is run as: {{{ bash.exe-3.1$ gcc -c test.c bash.exe-3.1$ ../ghc-init/inplace/bin/ghc-stage2 --make foo.hs -debug -fforce-recomp [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo.exe ... bash.exe-3.1$ ./foo foo.exe: Unknown PEi386 section name `.eh_frame' (while processing: test.o) foo.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 002c0154 (GHC version 7.7.20130905 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} More useful info: {{{ bash.exe-3.1$ objdump -s -j .text test.o test.o: file format pe-i386 Contents of section .text: 0000 5589e583 ec18c704 24000000 00e80000 U.......$....... 0010 0000c9c3 .... bash.exe-3.1$ objdump -r -j .text test.o test.o: file format pe-i386 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000009 dir32 .rdata 0000000e DISP32 _printf }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7684: cgrun071 segfaults
by GHC 06 Sep '13

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): I've unassigned myself since... (from two comments ago) > I'm not sure where to go from here, so I'll leave it to people more experienced than myself. If you want to continue giving pointers go right ahead, and I'll pick this back up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 06 Sep '13

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * owner: leroux => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 06 Sep '13

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): Alright, ran the gcc42 version in gdb and got a useful message. =) {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x000000010027f74b in hs_popcnt8 () (gdb) display/i $pc 1: x/i $pc 0x10027f74b <hs_popcnt8+11>: movzbl (%rdi,%rax,1),%eax }}} {{{ _hs_popcnt8: 000000010027f740 pushq %rbp 000000010027f741 movq %rsp, %rbp 000000010027f744 leaq _popcount_tab(%rip), %rax 000000010027f74b movzbl (%rdi,%rax), %eax <------- 0x10027f74b 000000010027f74f popq %rbp 000000010027f750 ret 000000010027f751 nopl (%rax) 000000010027f758 nopl (%rax,%rax) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 06 Sep '13

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): attachment:cgrun071-rts-asm-diffs.txt Both cgrun071 binaries are built, dumped, and diff'd as follows. {{{ $ ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no- user-package-db -rtsopts -ddump-to-file -ddump-asm -fno-ghci-history -o cgrun071 cgrun071.hs -O -fasm # TEST=cgrun071 WAY=normal EXTRA_HC_OPTS ="-ddump-to-file -ddump-asm" $ tool -tV cgrun071 > cgrun071.S # dump the object code }}} And then simply {{{ $ diff -y cgrun071-gcc48-passed.S cgrun071-gcc42-failed.S }}} The left side of the diff is from ghc (built with gcc48, passed) and the right is built with gcc42 (failed, segfault). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 06 Sep '13

06 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): Replying to [comment:48 parcs]: > > What are the advantages of adding an entry to `ghc --info` over conditioning on the version, in this case? Right now this is mostly for convenience - to enable supporting both the master version of GHC 7.7 and the parmake branch. In the future this will be less important - unless GHC HQ opts to disable parallel --make on some platforms for some reason. Implementing this is trivial: just add a `("Supports parallel --make", "YES")` tuple to the list returned by compiler/main/DynFlags.compilerInfo. I can write a patch myself if you want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 05 Sep '13

05 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:44 refold]: > Replying to [comment:22 parcs]: > > Is there some way to detect whether GHC has support for parallel `--make`? E.g. using `ghc --info`? I'd prefer to use that instead of conditioning on the version. What are the advantages of adding an entry to `ghc --info` over conditioning on the version, in this case? ---- GHC no longer deadlocks from its use of `setNumCapabilities` (see #8209) but there is still another related issue: GHC sometimes prints {{{ ghc-stage2: GHC.Event.Manager.loop: state is already Finished }}} when exiting. See #8235 ---- Ryan: That's really odd. I'm going to try `cabal install -j` with my branch later today and let you know how it goes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it
by GHC 05 Sep '13

05 Sep '13

#3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------------------+------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: Resolution: | 6.10.4 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | dynamic link Test Case: | Architecture: Blocking: 781, 1883, 2283, 3242, 3333, | Unknown/Multiple 3372, 3654, 4244, 5062, 5197, 5435, 6107, | Difficulty: 7043, 7056, 7072, 7097, 7103, 7134, 7316, | Unknown 7329, 7389, 7475, 7687 | Blocked By: 5987 | Related Tickets: -------------------------------------------------+------------------------- Old description: > In 6.14.1 we should switch to shipping a dynamically linked GHCi binary, > on those platforms for which dynamic linking is supported (currently > Linux; MacOS X and Windows support is in progress). > > == Advantages == > > * The GHCi binary is smaller > * some packages don't need to be loaded on startup: lower memory use > * GHCi startup might be quicker (or it might not) > * some hacks due to having two copies of the base package are not > necessary (see `rts/Globals.c`) > * We might save some space in the distributions. > * It takes us a step closer to not needing the RTS linker at all > * It takes us a step closer to using dynamic linking by default, which > is where we want to go ultimately > > == Potential Issues == > > * Do we run into any problems with GHCi and the user program sharing the > same > stdin/stdout/stderr handles? Do we need to virtualise these > explicitly in the > GHCi front end? > > * We cannot revert CAFs in packages that are shared by GHC and the user > program. > There are some old non-working hacks related to reverting CAFs when > GHCi is > dynamically linked (see `KeepCAFsForGHCi`) that > need to be cleaned out. CAFs can only be reverted in code loaded by > the RTS > linker. We need to think about whether this is a necessary feature or > not: > we have never supported CAF reverting for interpreted code anyway. > One > reason to have it was so that you can recover after saying > `getContents` at > the GHCi prompt, but we can provide other ways to work around that. > > * There will be installation/binary-dist issues to resolve; currently we > don't > install any dynamically-linked binaries. > > == Open questions == > > * Whether we continue to use the same binary for GHC and GHCi is an open > question: > it would be possible to provide a separate statically-linked GHC > binary if > performance of the dynamically-linked version was an issue. > > * We might as well dynamically-link Haddock, and the other tools that > come > with GHC too. New description: In 6.14.1 we should switch to shipping a dynamically linked GHCi binary, on those platforms for which dynamic linking is supported (currently Linux; MacOS X and Windows support is in progress). == Advantages == * The GHCi binary is smaller * some packages don't need to be loaded on startup: lower memory use * GHCi startup might be quicker (or it might not) * some hacks due to having two copies of the base package are not necessary (see `rts/Globals.c`) * We might save some space in the distributions. * It takes us a step closer to not needing the RTS linker at all * It takes us a step closer to using dynamic linking by default, which is where we want to go ultimately == Potential Issues == * Do we run into any problems with GHCi and the user program sharing the same stdin/stdout/stderr handles? Do we need to virtualise these explicitly in the GHCi front end? * We cannot revert CAFs in packages that are shared by GHC and the user program. There are some old non-working hacks related to reverting CAFs when GHCi is dynamically linked (see `KeepCAFsForGHCi`) that need to be cleaned out. CAFs can only be reverted in code loaded by the RTS linker. We need to think about whether this is a necessary feature or not: we have never supported CAF reverting for interpreted code anyway. One reason to have it was so that you can recover after saying `getContents` at the GHCi prompt, but we can provide other ways to work around that. However, if we eliminated HEAP_ALLOCED (#8199), as a side effect of this implementation, this might be doable, as we no longer have to reach our fingers into the data section of dynamically linked in libraries to revert a CAF; all of the CAFs are copied to dynamic memory space first. (The current implementation doesn't work for that, however!) * There will be installation/binary-dist issues to resolve; currently we don't install any dynamically-linked binaries. == Open questions == * Whether we continue to use the same binary for GHC and GHCi is an open question: it would be possible to provide a separate statically-linked GHC binary if performance of the dynamically-linked version was an issue. * We might as well dynamically-link Haddock, and the other tools that come with GHC too. -- Comment (by ezyang): If we eliminated HEAP_ALLOCED (#8199), as a side effect of this implementation, this might be doable, as we no longer have to reach our fingers into the data section of dynamically linked in libraries to revert a CAF; all of the CAFs are copied to dynamic memory space first. (The current implementation doesn't work for that, however!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3658#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 05 Sep '13

05 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): Maybe the confusion stems from that both the `POPCNT` implementation and the C fallback implementation have some supporting code in the native code generator, either to emit the instruction or to emit the C call? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0