Link error with head Re: [commit: ghc] master: GHCi: Properly generate jump code for ARM (#8380) (5bab1a5)

Hi, I'm having trouble linking with head:
[1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... Undefined symbols for architecture x86_64: "___builtin___clear_cache", referenced from: _flushExec in libHSrts.a(Storage.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
I get the impression that this commit is related. Is it the case that
Apple switched from gcc to clang recently? Could that be why
___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so
am kind of stuck.
On Sat, Nov 23, 2013 at 1:22 AM,
Repository : ssh://git@git.haskell.org/ghc
On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/5bab1a57f572e29dfdffd6d1ce8e53a277...
---------------------------------------------------------------
commit 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd Author: Austin Seipp
Date: Mon Nov 11 10:26:03 2013 -0600 GHCi: Properly generate jump code for ARM (#8380)
This adds code for jumping to given addresses for ARM, written by Ben Gamari.
However, when allocating new infotables for bytecode (which is where this jump code occurs), we need to be sure to flush the cache on the execute pointer returned from allocateExec() - on systems like ARM, the processor won't reliably read back code or automatically cache flush, where x86 will.
So we add a new flushExec primitive to call out to GCC's __builtin___clear_cache primitive, which will properly generate the correct code (nothing on x86, and a call to libgcc's __clear_cache on ARM) and make sure we use it after writing the code out.
Authored-by: Ben Gamari
Authored-by: Austin Seipp Signed-off-by: Austin Seipp ---------------------------------------------------------------
5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd compiler/ghci/ByteCodeItbls.lhs | 21 ++++++++++++++++++++- includes/rts/storage/GC.h | 1 + rts/Linker.c | 1 + rts/sm/Storage.c | 27 +++++++++++++++++++++++++++ 4 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/compiler/ghci/ByteCodeItbls.lhs b/compiler/ghci/ByteCodeItbls.lhs index 0d07be5..2180f87 100644 --- a/compiler/ghci/ByteCodeItbls.lhs +++ b/compiler/ghci/ByteCodeItbls.lhs @@ -227,6 +227,20 @@ mkJumpToAddr dflags a = case platformArch (targetPlatform dflags) of , fromIntegral (w64 .&. 0x0000FFFF) , fromIntegral ((w64 `shiftR` 32) .&. 0x0000FFFF) ]
+ ArchARM { } -> + -- Generates Thumb sequence, + -- ldr r1, [pc, #0] + -- bx r1 + -- + -- which looks like: + -- 00000000 <.addr-0x8>: + -- 0: 4900 ldr r1, [pc] ; 8 <.addr> + -- 4: 4708 bx r1 + let w32 = fromIntegral (ptrToInt a) :: Word32 + in Left [ 0x49, 0x00 + , 0x47, 0x08 + , byte0 w32, byte1 w32, byte2 w32, byte3 w32] + arch -> panic ("mkJumpToAddr not defined for " ++ show arch)
@@ -374,11 +388,16 @@ load = do addr <- advance newExecConItbl :: DynFlags -> StgConInfoTable -> IO (FunPtr ()) newExecConItbl dflags obj = alloca $ \pcode -> do - wr_ptr <- _allocateExec (fromIntegral (sizeOfConItbl dflags obj)) pcode + let sz = fromIntegral (sizeOfConItbl dflags obj) + wr_ptr <- _allocateExec sz pcode ex_ptr <- peek pcode pokeConItbl dflags wr_ptr ex_ptr obj + _flushExec sz ex_ptr -- Cache flush (if needed) return (castPtrToFunPtr ex_ptr)
foreign import ccall unsafe "allocateExec" _allocateExec :: CUInt -> Ptr (Ptr a) -> IO (Ptr a) + +foreign import ccall unsafe "flushExec" + _flushExec :: CUInt -> Ptr a -> IO () \end{code} diff --git a/includes/rts/storage/GC.h b/includes/rts/storage/GC.h index 8133496..f8b8afe 100644 --- a/includes/rts/storage/GC.h +++ b/includes/rts/storage/GC.h @@ -161,6 +161,7 @@ typedef void* AdjustorWritable; typedef void* AdjustorExecutable;
AdjustorWritable allocateExec(W_ len, AdjustorExecutable *exec_addr); +void flushExec(W_ len, AdjustorExecutable exec_addr); #if defined(ios_HOST_OS) AdjustorWritable execToWritable(AdjustorExecutable exec); #endif diff --git a/rts/Linker.c b/rts/Linker.c index 77943a5..14ebac3 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -1350,6 +1350,7 @@ typedef struct _RtsSymbolVal { SymI_HasProto(g0) \ SymI_HasProto(allocate) \ SymI_HasProto(allocateExec) \ + SymI_HasProto(flushExec) \ SymI_HasProto(freeExec) \ SymI_HasProto(getAllocations) \ SymI_HasProto(revertCAFs) \ diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c index 112ad83..c1a1a5a 100644 --- a/rts/sm/Storage.c +++ b/rts/sm/Storage.c @@ -1152,6 +1152,15 @@ AdjustorWritable allocateExec (W_ bytes, AdjustorExecutable *exec_ret) return (ret + 1); }
+void flushExec (W_ len, AdjustorExecutable exec_addr) +{ + /* On ARM and other platforms, we need to flush the cache after + writing code into memory, so the processor reliably sees it. */ + unsigned char* begin = (unsigned char*)exec_addr; + unsigned char* end = begin + len; + __builtin___clear_cache(begin, end); +} + // freeExec gets passed the executable address, not the writable address. void freeExec (AdjustorExecutable addr) { @@ -1198,6 +1207,15 @@ AdjustorWritable execToWritable(AdjustorExecutable exec) return writ; }
+void flushExec (W_ len, AdjustorExecutable exec_addr) +{ + /* On ARM and other platforms, we need to flush the cache after + writing code into memory, so the processor reliably sees it. */ + unsigned char* begin = (unsigned char*)exec_addr; + unsigned char* end = begin + len; + __builtin___clear_cache(begin, end); +} + void freeExec(AdjustorExecutable exec) { AdjustorWritable writ; @@ -1251,6 +1269,15 @@ AdjustorWritable allocateExec (W_ bytes, AdjustorExecutable *exec_ret) return ret; }
+void flushExec (W_ len, AdjustorExecutable exec_addr) +{ + /* On ARM and other platforms, we need to flush the cache after + writing code into memory, so the processor reliably sees it. */ + unsigned char* begin = (unsigned char*)exec_addr; + unsigned char* end = begin + len; + __builtin___clear_cache(begin, end); +} + void freeExec (void *addr) { StgPtr p = (StgPtr)addr - 1;
_______________________________________________ ghc-commits mailing list ghc-commits@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

Sorry for the noise, it turns out there's already a trac ticket:
https://ghc.haskell.org/trac/ghc/ticket/8561
(I didn't find it because I was searching for ___builtin… instead of __builtin!)
On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson
Hi, I'm having trouble linking with head:
[1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... Undefined symbols for architecture x86_64: "___builtin___clear_cache", referenced from: _flushExec in libHSrts.a(Storage.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
I get the impression that this commit is related. Is it the case that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so am kind of stuck.
--SNIP--

It's because you're using GCC 4.2 on your Mac. It's not in GCC till 4.3. But should be cppd so that it's not used on x86 architectures so that this use doesn't happen On Monday, November 25, 2013, Amos Robinson wrote:
Sorry for the noise, it turns out there's already a trac ticket: https://ghc.haskell.org/trac/ghc/ticket/8561 (I didn't find it because I was searching for ___builtin… instead of __builtin!)
Hi, I'm having trouble linking with head:
[1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... Undefined symbols for architecture x86_64: "___builtin___clear_cache", referenced from: _flushExec in libHSrts.a(Storage.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson
javascript:;> wrote: 5658) (LLVM build 2336.11.00) I get the impression that this commit is related. Is it the case that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so am kind of stuck.
--SNIP-- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs

I'll cook up a patch and post it to trac in the next hour. On Tuesday, November 26, 2013, Carter Schonwald wrote:
It's because you're using GCC 4.2 on your Mac. It's not in GCC till 4.3.
But should be cppd so that it's not used on x86 architectures so that this use doesn't happen
On Monday, November 25, 2013, Amos Robinson wrote:
Sorry for the noise, it turns out there's already a trac ticket: https://ghc.haskell.org/trac/ghc/ticket/8561 (I didn't find it because I was searching for ___builtin… instead of __builtin!)
On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson
wrote: Hi, I'm having trouble linking with head:
[1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... Undefined symbols for architecture x86_64: "___builtin___clear_cache", referenced from: _flushExec in libHSrts.a(Storage.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
I get the impression that this commit is related. Is it the case that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so am kind of stuck.
--SNIP-- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Thanks so much, Carter.
What I'm still confused about is this: I was able to build stage 1 and
then build stage 2 using stage 1. However, if I try building anything
with either stage, it won't link. How was it able to link stage 2?
On Tue, Nov 26, 2013 at 4:27 PM, Carter Schonwald
I'll cook up a patch and post it to trac in the next hour.
On Tuesday, November 26, 2013, Carter Schonwald wrote:
It's because you're using GCC 4.2 on your Mac. It's not in GCC till 4.3.
But should be cppd so that it's not used on x86 architectures so that this use doesn't happen
On Monday, November 25, 2013, Amos Robinson wrote:
Sorry for the noise, it turns out there's already a trac ticket: https://ghc.haskell.org/trac/ghc/ticket/8561 (I didn't find it because I was searching for ___builtin… instead of __builtin!)
On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson
wrote: Hi, I'm having trouble linking with head:
[1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... Undefined symbols for architecture x86_64: "___builtin___clear_cache", referenced from: _flushExec in libHSrts.a(Storage.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
I get the impression that this commit is related. Is it the case that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so am kind of stuck.
--SNIP-- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

No clue. I'll find out once I get on my computer. I think Mebe because stage 1 has no ghci? Pure ignorant speculation mind you. Please be sure to test the fix once I put it on trac (I'll test too of course. ) On Tuesday, November 26, 2013, Amos Robinson wrote:
Thanks so much, Carter.
What I'm still confused about is this: I was able to build stage 1 and then build stage 2 using stage 1. However, if I try building anything with either stage, it won't link. How was it able to link stage 2?
I'll cook up a patch and post it to trac in the next hour.
On Tuesday, November 26, 2013, Carter Schonwald wrote:
It's because you're using GCC 4.2 on your Mac. It's not in GCC till
4.3.
But should be cppd so that it's not used on x86 architectures so that
On Tue, Nov 26, 2013 at 4:27 PM, Carter Schonwald
javascript:;> wrote: this use doesn't happen
On Monday, November 25, 2013, Amos Robinson wrote:
Sorry for the noise, it turns out there's already a trac ticket: https://ghc.haskell.org/trac/ghc/ticket/8561 (I didn't find it because I was searching for ___builtin… instead of __builtin!)
On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <
amos.robinson@gmail.com javascript:;>
wrote:
Hi, I'm having trouble linking with head:
[1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... Undefined symbols for architecture x86_64: "___builtin___clear_cache", referenced from: _flushExec in libHSrts.a(Storage.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
I get the impression that this commit is related. Is it the case that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so am kind of stuck.
--SNIP-- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs

Austin indicates he's got a fix already on his merge queue, in the mean time just delete the offending code (if you're on an x86/ 64 system) and the build should work On Tue, Nov 26, 2013 at 12:48 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
No clue. I'll find out once I get on my computer. I think Mebe because stage 1 has no ghci? Pure ignorant speculation mind you. Please be sure to test the fix once I put it on trac (I'll test too of course. )
On Tuesday, November 26, 2013, Amos Robinson wrote:
Thanks so much, Carter.
What I'm still confused about is this: I was able to build stage 1 and then build stage 2 using stage 1. However, if I try building anything with either stage, it won't link. How was it able to link stage 2?
I'll cook up a patch and post it to trac in the next hour.
On Tuesday, November 26, 2013, Carter Schonwald wrote:
It's because you're using GCC 4.2 on your Mac. It's not in GCC till
4.3.
But should be cppd so that it's not used on x86 architectures so that
use doesn't happen
On Monday, November 25, 2013, Amos Robinson wrote:
Sorry for the noise, it turns out there's already a trac ticket: https://ghc.haskell.org/trac/ghc/ticket/8561 (I didn't find it because I was searching for ___builtin… instead of __builtin!)
On Tue, Nov 26, 2013 at 3:39 PM, Amos Robinson <
amos.robinson@gmail.com>
wrote:
Hi, I'm having trouble linking with head:
> [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, > bindisttest/HelloWorld.o ) > Linking bindisttest/HelloWorld ... > Undefined symbols for architecture x86_64: > "___builtin___clear_cache", referenced from: > _flushExec in libHSrts.a(Storage.o) > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status
This is on OSX 10.8.5, where gcc --version gives me > i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. > build 5658) (LLVM build 2336.11.00)
I get the impression that this commit is related. Is it the case
On Tue, Nov 26, 2013 at 4:27 PM, Carter Schonwald
wrote: this that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing?
I'm sorry, I don't really know anything about the runtime system, so am kind of stuck.
--SNIP-- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
participants (2)
-
Amos Robinson
-
Carter Schonwald