April 2015 - ghc-tickets

[GHC] #8552: Rename StgArrWords to StgArrBytes
by GHC 15 Sep '15

15 Sep '15

#8552: Rename StgArrWords to StgArrBytes ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Since #3800, `StgArrWords` contains a certain number of words and not bytes. One can easily forget this and make programming mistakes. For example if you try to store the number of words in the `bytes` field, the garbage collector won't honor your decision. (I learned the hard way :)) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available
by GHC 08 Sep '15

08 Sep '15

#10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We seem to fill in the `--with-hscolour=` flag with an empty string, which causes a plain old build failure. Configure probably ought to fail if `HSCOLOUR_SRCS=YES` and there is no hscolours. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped
by GHC 07 Sep '15

07 Sep '15

#9087: Executables in the 7.8.2 Linux i386 binary tarball are not stripped ----------------------------+-------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------- At least on i386 Linux, the executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes: {{{ $ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock }}} Do we really need to include the debug info for exes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9500: Allow GHC defaults to be modified with an environment variable
by GHC 07 Sep '15

07 Sep '15

#9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I wanted to do this to turn -fsimple-list-literals on and off for NoFib without editing a million makefiles or recompiling GHC, but I bet there are other reasons. GHC's validate should probably prompt the user to verify they want to continue of the variable is set, and should issue a loud warning at the very end indicating what options were set by the variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)"
by GHC 06 Sep '15

06 Sep '15

#8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ----------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- I have a program (git-annex) which builds successfully on windows, but when I enable any of three optional features which pull in some additional libraries, it fails to link. I will attach the output of cabal build --ghc-options=-v for a failing and a successful build. I hypothesize this is due to a command line length limit. The final failing gcc link command is 43814 characters, vs 30765 in the configuration that succeeds. Right around the 32k boundry. Not sure what I can do to work around this, short of splitting up my program into standalone libraries which will link without referencing every individual module? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8614: Duplicate symbol error when loading text twice
by GHC 05 Sep '15

05 Sep '15

#8614: Duplicate symbol error when loading text twice ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We are developing some FFI binding to some Kinect Camera library, and came across the following: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Honi Prelude Honi> import Honi.Types Prelude Honi Honi.Types> initialize 2 Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package honi-0.1.0.0 ... can't load .so/.DLL for: libfreenect.so (libfreenect.so: cannot open shared object file: No such file or directory) Prelude Honi Honi.Types> Right [d] <- getDeviceList Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol __stginit_textzm0zi11zi3zi1_DataziText whilst processing object file /home/niklas/.cabal/lib/x86_64-linux- ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} Apparently, ghci has no problem linking packages like array and deepseq twice, but when it comes across loading text another time, we get this duplicate symbol error. Does this make sense? Why does it not detect that text is already linked, like for the other packages? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8290: lookupSymbol API is unsafe
by GHC 05 Sep '15

05 Sep '15

#8290: lookupSymbol API is unsafe -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- lookupSymbol is one of those functions that looks nice and innocuous on the tin, until you realize actually it doesn't actually do what you want, and seduces you into writing code that doesn't work on Mac OS X. Case in point, this recent test suite commit: {{{ commit 29b0521cd9be39b4026103d184d1fec14ef3bc22 Author: Edward Z. Yang <ezyang(a)mit.edu> Date: Fri Sep 13 20:52:57 2013 -0700 Properly provide leading underscore when necessary. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> }}} Yes, the API is "correct" in some sense, but from a portability sense, we really want the function to add the underscore itself. If we change this particular function, we will probably break most dynamic loading code (including GHC's). We could also add a safe variant of the function. We just need to decide something to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8926: GHC makes unsound references in object code
by GHC 05 Sep '15

05 Sep '15

#8926: GHC makes unsound references in object code ----------------------------+---------------------------------------------- Reporter: | Owner: anton.dubovik | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- To reproduce the bug run script `run.sh` from the attached archive. It will: 1. install `FooPackage` {{{ Resolving dependencies... Configuring FooPackage-0.1... Building FooPackage-0.1... Preprocessing library FooPackage-0.1... [1 of 1] Compiling FooPackage ( src\FooPackage.hs, dist\build\FooPackage.o ) In-place registering FooPackage-0.1... Installing library in C:\Users\Anton\AppData\Roaming\cabal\i386-windows- ghc-7.6.3\FooPackage-0.1 Registering FooPackage-0.1... Installed FooPackage-0.1 }}} 2. compile executable `Client1` which depends on `FooPackage` {{{ [1 of 3] Compiling QuxClient ( QuxClient.hs, obj\QuxClient.o ) [2 of 3] Compiling BarClient ( BarClient.hs, obj\BarClient.o ) [3 of 3] Compiling Client1 ( Client1.hs, obj\Client1.o ) Linking exes/Client1.exe ... }}} 3. compile executable `Client2` which doesn't depend on `FooPackage` At the third step GHC will fall with linker error: {{{ [2 of 2] Compiling Client2 ( Client2.hs, obj\Client2.o ) Linking exes/Client2.exe ... obj\BarClient.o:fake:(.text+0x83): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_info' obj\BarClient.o:fake:(.data+0x10): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_closure' collect2: ld returned 1 exit status }}} Both `Client1` and `Client2` import `BarClient` module that doesn't depends on `FooPackage`. `Client1` imports `QuxClient` that imports `FooPackage`: {{{ module QuxClient where import FooPackage(foo) import Data.Set qux :: Set String -> Set String qux = foo }}} {{{ module BarClient where import Data.Set bar :: Set String -> Set String bar s = insert "bar" s }}} `FooPackage` uses function `Data.Set.insert` which is marked at `Data.Set` as `INLINABLE`: {{{ module FooPackage where import Data.Set foo :: Set String -> Set String foo s = insert "foo" s }}} GHC emphasizes in interface file, that `FooPackage.o` contains specialized version of `Data.Set.insert`: {{{ > ghc --show-iface FooPackage.hi ... "SPEC Data.Set.Base.insert [GHC.Base.String]" [ALWAYS] forall $dOrd :: GHC.Classes.Ord GHC.Base.String Data.Set.Base.insert @ [GHC.Types.Char] $dOrd = FooPackage.$sinsert ... }}} Later GHC see again the use of `Data.Set.insert@String` at `BarClient` and decides to apply this specialise rule, so that `BarClient` now has reference to `FooPackage`: {{{ > ghc --show-iface BarClient.hi ... bar :: Data.Set.Base.Set GHC.Base.String -> Data.Set.Base.Set GHC.Base.String {- Arity: 1, Strictness: S, Unfolding: (\ s :: Data.Set.Base.Set GHC.Base.String -> FooPackage.$sinsert_$sgo5 BarClient.bar1 s) -} ... }}} `Client2` doesn't depend on `FooPackage`, thus linker throws an error. There are plenty of workarounds here, but all of them are ad hoc (1,2,3) or could affect performance (4): 1. Change the order of `BarClient` and `QuxClient` imports in `Client1` module. 2. Compile `Client1` and `Client2` in opposite order. 3. Add fake import at `Client2` module: {{{ import FooPackage() }}} 4. Build `FooPackage` with ghc-option `-fomit-interface-pragmas`. That will eraise from `FooPackage.hi` all specialisation rules as well as information about strictness and inlining. Some information about the environment: {{{ > ghc-pkg list ... containers-0.5.0.0 base-4.6.0.1 ... > ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 > cabal --version cabal-install version 1.18.0.3 using version 1.18.1.3 of the Cabal library }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9989: GHCI is slow for precompiled code
by GHC 04 Sep '15

04 Sep '15

#9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello! We found that loading compiled and optimised `accelerate` code into ghci works much much slower than code run directly. (I'm marking it as a ghc-api bug, because I noticed this behavior while using it) Here is the example: {{{#!hs module Main where import Data.Array.Accelerate as A import Data.Array.Accelerate.CUDA as C import Data.Time.Clock (diffUTCTime, getCurrentTime) main :: IO () main = do start <- getCurrentTime print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) [1..1000000] :: Vector Double) end <- getCurrentTime print $ diffUTCTime end start }}} When I compile it and run $ ghc -O2 Main.hs -threaded [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main Array (Z) [1000001.0] 0.162204s It takes `0.16 s` to finish When I compile it and load into ghci: $ ghc -O2 -dynamic -c Main.hs $ ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package transformers-0.3.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package SafeSemaphore-0.10.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package fclabels-2.0.2.2 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package hashable-1.2.3.1 ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package hashtables-1.2.0.1 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package accelerate-0.15.0.0 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package cryptohash-0.11.6 ... linking ... done. Loading package cuda-0.6.5.1 ... linking ... done. Loading package exception-transformers-0.3.0.4 ... linking ... done. Loading package exception-mtl-0.3.0.5 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.18.6 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package th-lift-0.7 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.4 ... linking ... done. Loading package th-reify-many-0.1.2 ... linking ... done. Loading package th-orphans-0.8.3 ... linking ... done. Loading package haskell-src-meta-0.6.0.8 ... linking ... done. Loading package srcloc-0.4.1 ... linking ... done. Loading package mainland-pretty-0.2.7 ... linking ... done. Loading package symbol-0.2.4 ... linking ... done. Loading package language-c-quote-0.8.0 ... linking ... done. Loading package accelerate-cuda-0.15.0.0 ... linking ... done. Array (Z) [1000001.0] 0.256128s It takes `0.26 s` to finish. On other computer, using `criterion`, we observed even a `50x` difference. Why is it working so slow, isn't ghci just to load function and simply call it? Here is how execution time changes for different matrix sizes. For comparison we have also measured time of interpreted code (without precompiling). {{{ size | compiled | precompiled | interpreted ---------+-----------+--------------+------------ 100 | 0.054076s | 0.082686s | 0.151857s 1000 | 0.054509s | 0.08305s | 0.135452s 10000 | 0.055405s | 0.08469s | 0.12632s 100000 | 0.057768s | 0.093011s | 0.155359s 1000000 | 0.089811s | 0.251359s | 0.202022s 10000000 | 0.397642s | 1.400603s | 0.898547s }}} We believe that problem lies on the side of `ghci` rather than `accelerate`, how could we confirm this? Moreover and even more important is there any workaround for it, if we need this precompiled code running fast in production environment? Any guidance will be appreciated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects
by GHC 04 Sep '15

04 Sep '15

#9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- '''Summary''': Given two object files (created from C files) A and B, where B refers to symbols defined in A, if we load B before A, calling `resolveObjs` after each object file, symbol resolution goes wrong. Full test case attached. '''Detailed description''': Consider {{{#!c // a.c #include <stdio.h> void defined_in_A() { printf("In A\n"); } }}} {{{#!c // b.c #include <stdio.h> void defined_in_A(); void defined_in_B() { printf("In B\n"); defined_in_A(); printf("In B\n"); } }}} and {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Main where import System.IO foreign import ccall "defined_in_B" defined_in_B :: IO () main :: IO () main = defined_in_B }}} and we use the GHC API to load the object files `a.o` and `b.o` (corresponding to `a.c` and `b.c`), calling `resolveObjs` after loading each object, and then load `Main` and call `Main.main`, everything works fine (the attached test case contains both `a.c`, `b.c` and `Main.hs` as well as the test program that calls into the GHC API). However, if we load `b.o` ''before'' `a.o`, things go wrong. When we load `b.o` and call `resolveObjs` then `resolveObjs` (quite reasonably) complains that {{{ lookupSymbol failed in relocateSection (relocate external) b.o: unknown symbol `_defined_in_A' }}} since we haven't loaded `a.o` yet. But when we then load `a.o` and call `resolveObjs` again, `resolveObjs` reports okay, but something goes wrong because the program subsequently segfaults. '''A successful run''' I took a closer look at what happens exactly. First, let's consider the test run where we load A before B, and everything works fine, and let's look at the precise code that we actually execute when `Main.main` does the foreign call to `defined_in_B`: {{{ # lldb Linkerbug Current executable set to 'Linkerbug' (x86_64). (lldb) breakpoint set -n ffi_call Breakpoint 1: where = Linkerbug`ffi_call + 29 at ffi64.c:421, address = 0x0000000102be2eed (lldb) run Process 92361 launched: 'Linkerbug' (x86_64) Loading object "a.o" symbol resolution ok Loading object "b.o" symbol resolution ok Loading Haskell module "Main.hs" ok Running "Main.main" Process 92361 stopped * thread #1: tid = 0x32048b, 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421 (lldb) disassemble -c 14 -s fn 0x104c6c210: pushq %rbp 0x104c6c211: movq %rsp, %rbp 0x104c6c214: pushq %rbx 0x104c6c215: pushq %rax 0x104c6c216: leaq 0x1d(%rip), %rbx 0x104c6c21d: movq %rbx, %rdi 0x104c6c220: callq 0x104c6c3c8 0x104c6c225: xorl %eax, %eax 0x104c6c227: callq 0x104c6b210 0x104c6c22c: movq %rbx, %rdi 0x104c6c22f: addq $0x8, %rsp 0x104c6c233: popq %rbx 0x104c6c234: popq %rbp 0x104c6c235: jmpq 0x104c6c3c8 }}} This disassembly is the compiled code for B which, in order, does a call to `printf`, then to `defined_in_A`, and then back to `printf` (the last call is `jmpq` rather than `callq`: the C compiler did a tail call optimization). Let's make sure that this is actually true; the first call is a call to {{{ (lldb) disassemble -c 2 -s 0x104c6c3c8 0x104c6c3c8: jmpq *-0xe(%rip) 0x104c6c3ce: addb %al, (%rax) }}} which is an indirect jump to {{{ (lldb) memory read -f A -c 1 "0x104c6c3ce - 0xe" 0x104c6c3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} to `puts`, okay, good. Seems an unnecessary level of indirection, but that's okay. The next call is to {{{ (lldb) disassemble -c 5 -s 0x104c6b210 0x104c6b210: pushq %rbp 0x104c6b211: movq %rsp, %rbp 0x104c6b214: leaq 0x6(%rip), %rdi 0x104c6b21b: popq %rbp 0x104c6b21c: jmpq 0x104c6b370 }}} which is the compiled code for `defined_in_A`, which should be just a call to `printf`. Let's confirm: {{{ (lldb) disassemble -c 2 -s 0x104c6b370 0x104c6b370: jmpq *-0xe(%rip) 0x104c6b376: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6b376 - 0xe" 0x104c6b368: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} Ok, all good. '''A failed run''' Now let's check what happens when we load the objects in the opposite order. The code that we execute is {{{ (lldb) disassemble -c 14 -s fn 0x104c6b210: pushq %rbp 0x104c6b211: movq %rsp, %rbp 0x104c6b214: pushq %rbx 0x104c6b215: pushq %rax 0x104c6b216: leaq 0x1d(%rip), %rbx 0x104c6b21d: movq %rbx, %rdi 0x104c6b220: callq 0x104c6b3c8 0x104c6b225: xorl %eax, %eax 0x104c6b227: callq 0x104c6c210 0x104c6b22c: movq %rbx, %rdi 0x104c6b22f: addq $0x8, %rsp 0x104c6b233: popq %rbx 0x104c6b234: popq %rbp 0x104c6b235: jmpq 0x104c6b556 }}} This immediately looks suspicious: the address of the `jmpq` (the second -- tail -- call to `printf`) is different from the first. The first `callq` is okay: {{{ (lldb) disassemble -c 2 -s 0x104c6b3c8 0x104c6b3c8: jmpq *-0xe(%rip) 0x104c6b3ce: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6b3ce - 0xe" 0x104c6b3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} and the call to `defined_in_A`, as well as the code ''for'' `defined_in_A`, are both ok: {{{ (lldb) disassemble -c 5 -s 0x104c6c210 0x104c6c210: pushq %rbp 0x104c6c211: movq %rsp, %rbp 0x104c6c214: leaq 0x6(%rip), %rdi 0x104c6c21b: popq %rbp 0x104c6c21c: jmpq 0x104c6c370 (lldb) disassemble -c 2 -s 0x104c6c370 0x104c6c370: jmpq *-0xe(%rip) 0x104c6c376: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6c376 - 0xe" 0x104c6c368: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} However, that second call to `printf` (the `jmpq`) in `defined_in_B` is indeed wrong: it's jumping into nowhere: {{{ (lldb) memory read -c 8 0x104c6b556 0x104c6b556: 00 00 00 00 00 00 00 00 ........ }}} Note that somewhat surprisingly is it ''not'' the resolution of the symbol from `a.o` that is wrong; that ''does'' get resolved okay once we load `a.o`; rather, it is the jump to `puts` which is wrong (and then only the one of them). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5