- ghc-tickets - Haskell.org

[GHC] #8241: GHCi showing its internals with malformed instance
by GHC 06 Sep '13

06 Sep '13

#8241: GHCi showing its internals with malformed instance ------------------------------------+------------------------------------- Reporter: crntaylor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Using ghci 7.4.2 I observe the following behaviour when I enter a malformed instance for a type class: Prelude> instance Eq a => Eq b => Eq (a -> b) where (==) = undefined *** Exception: compiler\rename\RnSource.lhs:430:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) I assume that ghci shouldn't be showing its internals like this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 06 Sep '13

06 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by ezyang): At least my version of GCC still outputs init_array sections. Honestly, I'm pretty surprised MingW GCC still emits constr. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 06 Sep '13

06 Sep '13

#8039: RTS linker: unloadObj() does not actually unload the code --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: rts/linker_unload | Blocked By: Blocking: 7746 | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonmar): Created #8238 to track unloading of shared libraries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 06 Sep '13

06 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by simonmar): @ezyang: compile some C++ code with a static constructor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7746: Support loading/unloading profiled objects from a profiled executable
by GHC 06 Sep '13

06 Sep '13

#7746: Support loading/unloading profiled objects from a profiled executable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5435, 8039 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * blockedby: => 5435, 8039 Old description: > This is closely related to #3360, but it is a bit less ambitious and > should be possible to implement without too many extra changes to the > byte code compiler and interpreter (e.g. we just have to teach the linker > how to handle things). Here is a simple test program off of 'plugins' to > get working: > > {{{ > {-# LANGUAGE ScopedTypeVariables #-} > > import System.Plugins.Make > import System.Plugins.Load > import Data.List > > boot :: FilePath -> IO () > boot path = do > r <- make path ["-prof"] > case r of > MakeSuccess _ p -> do > r' <- load p [] [] "result" > case r' of > LoadSuccess _ (v :: Int) -> print v > LoadFailure msg -> print msg > MakeFailure es -> putStrLn ("Failed: " ++ intercalate " " es) > > main = do > boot "Foo.hs" > }}} > > where Foo.hs is > > {{{ > module Foo where > result = 2 :: Int > }}} > > Here are the things that, as far as I can tell, need to be handled: > > * We should ensure consistency between the host and the object file > being uploaded. For example, if you load an un-profiled object file into > a profiled binary, GHC will eat all your puppies. A simple way to do this > is look for a symbol (e.g. CC_LIST) which is only ever exported when > something is profiled and barf it is encountered. > > * This current code fails with {{{test: Foo.o: unknown symbol > `CC_LIST'}}}, much the same way GHCi used to fail. This particular > problem is (I think) that we don’t store CC_LIST and other externsymbols > in our global hash table, so the linker thinks that they don’t exist, > when they do. CC_LIST and friends should be special-cased or added to the > table. > > * We don’t run ctors which setup CC_LIST with all of the cost-centres > from the loaded module; we need to teach the linker to do that (that's > the {{{/* ignore constructor section for now */}}}) > > * We need to come up with some sensible way of unloading cost-centres > from CC_LIST and friends; we could make CC_LIST doubly-linked and then > just excise the cost-centre in a destructor, but freeing the actual > allocated CostCentre is more difficult. For now, we might just live with > the memory leak, but see wiki:"Commentary/ResourceLimits#Memoryleaks" for > a possible better implementation strategy. > > But that’s it; everything else should work normally. Something similar > should apply to ticky builds. Something we will have to think about is > how to handle these special-cases as we move from static objects to > dynamic objects and push more of the runtime linking burden to the > standard libraries. New description: This is closely related to #3360, but it is a bit less ambitious and should be possible to implement without too many extra changes to the byte code compiler and interpreter (e.g. we just have to teach the linker how to handle things). Here is a simple test program off of 'plugins' to get working: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Plugins.Make import System.Plugins.Load import Data.List boot :: FilePath -> IO () boot path = do r <- make path ["-prof"] case r of MakeSuccess _ p -> do r' <- load p [] [] "result" case r' of LoadSuccess _ (v :: Int) -> print v LoadFailure msg -> print msg MakeFailure es -> putStrLn ("Failed: " ++ intercalate " " es) main = do boot "Foo.hs" }}} where Foo.hs is {{{ module Foo where result = 2 :: Int }}} Here are the things that, as far as I can tell, need to be handled: * We should ensure consistency between the host and the object file being uploaded. For example, if you load an un-profiled object file into a profiled binary, GHC will eat all your puppies. A simple way to do this is look for a symbol (e.g. CC_LIST) which is only ever exported when something is profiled and barf it is encountered. * This current code fails with {{{test: Foo.o: unknown symbol `CC_LIST'}}}, much the same way GHCi used to fail. This particular problem is (I think) that we don’t store CC_LIST and other externsymbols in our global hash table, so the linker thinks that they don’t exist, when they do. CC_LIST and friends should be special-cased or added to the table. I have a patch for that; it's pretty easy. * We don’t run ctors which setup CC_LIST with all of the cost-centres from the loaded module; we need to teach the linker to do that. The relevant bug is #5435. * We need to come up with some sensible way of unloading cost-centres from CC_LIST and friends; we could make CC_LIST doubly-linked and then just excise the cost-centre in a destructor, but freeing the actual allocated CostCentre is more difficult. For now, we might just live with the memory leak, but see wiki:"Commentary/ResourceLimits#Memoryleaks" for a possible better implementation strategy. Whatever cleanup is done here should be registered as a destructor for the library. Maybe #8039 solves this problem. * Tests! But that’s it; everything else should work normally. Something similar should apply to ticky builds. Sans destructors, there is a good chance this shindig may already work for dynamically linked apps. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7746#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 06 Sep '13

06 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by ezyang): These patches could probably be improved by adding .ctors support for ELF, and .init/.init_array for PEi386, but I don't know how to make my GCC on the respective platforms emit those types of sections to test. They might not even be accepted by the system linker; I have no way of telling. I also have pretty reasonable test (essentially a cleaned up version of #8237) which should get added to the test suite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3333: GHCi doesn't load weak symbols
by GHC 06 Sep '13

06 Sep '13

#3333: GHCi doesn't load weak symbols ---------------------------------+----------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: weak, dynamic loading Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: ---------------------------------+----------------------------------------- Comment (by ezyang): igloo: If the patch is already implemented and does not cause any trouble for anybody, I think we should take it. It is not that complicated either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3333#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 06 Sep '13

06 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #3658 -------------------------------------+------------------------------------ Old description: > As far as I can tell from my experimentation, any library that contains a > function with __attribute__((constructor)) on it won't have its > constructor(s) run when loaded, or its destructors run when unloaded. > This violates assumptions that some libraries make. New description: As far as I can tell from my experimentation, any library that contains a function with `__attribute__((constructor))` on it won't have its constructor(s) run when loaded, or its destructors run when unloaded. This violates assumptions that some libraries make. -- Comment (by ezyang): Note that GHC itself uses constructor (but not destructor) for profiling and foreign exports, so at least the constructor half of this problem is important. I'm attaching implementations for ELF and PEi386; Mach-O coming when I get a Mac to do testing on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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