September 2013 - ghc-tickets

Re: [GHC] #7980: runghc dies silently when given large numbers of arguments. Compiled code does not.
by GHC 06 Sep '13

06 Sep '13

#7980: runghc dies silently when given large numbers of arguments. Compiled code does not. ------------------------------------------------+-------------------------- Reporter: totherme | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I'm going to mark this as fixed since `runghc` no longer dies silently when given too many arguments. It's a little annoying that because `runghc` packs its argument list into a single argument to `ghc`, the effective maximum argument list size for `runghc` is quite a lot smaller than it would be for the compiled program, because of the two different limits in Linux. But I'm going to chalk that up to an oddity of Linux; there would always be *some* difference in maximum argument list size. If this really bothers someone, they can open a new ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7980#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8239: Wrong link in docs
by GHC 06 Sep '13

06 Sep '13

#8239: Wrong link in docs ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- trivial mistake, see https://github.com/nomeata/ghc/compare/fixlink and pull with {{{ git pull https://github.com/nomeata/ghc fixlink }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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