Trying to compile ghc HEAD on xubuntu 13.04-x64
Hey, because I have touble with ghci and packages with FFI, it was suggested to me to compile and use ghc HEAD. I am on xubuntu 13.04 64bit and try to do a perf build. It fails with: compiler/ghc.mk:478: warning: ignoring old commands for target `compiler/stage2/build/libHSghc-7.7.20131004-ghc7.7.20131004.so' /home/ls/src/ghc/inplace/bin/haddock --odir=libraries/ghc-prim/dist-install/doc/html/ghc-prim --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title=ghc-prim-0.3.1.0: GHC primitives --prologue=libraries/ghc-prim/dist-install/haddock-prologue.txt --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-O --optghc=-H64m --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /366) in 'GHC.PrimopWrappers' 72% (813 /1132) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20131004 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make: *** [all] Error 2 Suggestions? Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Size of crosscompiled exectuable
On 01/26/2013 09:24 AM, Nathan Hüsken wrote: On 01/25/2013 05:45 PM, Simon Marlow wrote: On 25/01/13 16:35, Simon Marlow wrote: On 25/01/13 15:51, Stephen Paul Weber wrote: Somebody claiming to be Simon Marlow wrote: On 25/01/13 13:58, Nathan Hüsken wrote: A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Not sure what you mean by five times the size on my linux system. What is 5 times larger than what? He's saying that the size of the android executable (made by his cross compiler) is five time the sive of the equivalent Ubuntu executable (made by, I assume, his system's GHC). Yes, exactly. Sorry for my bad phrasing. The problem is not the size, but the size ratio. Ah, I see. Yes, my executables are a similar size. I'm not sure why, I'll try to look into it. It's just the lack of SPLIT_OBJS. Also, unregisterised accounts for a factor of 1.5 or so. What exactly does SPLIT_OBJS do? Is there a chance to get it working for cross platform? There must be a lot of unused code in the exectuable. Is there no way to remove it? 5 Mb is rather large for an android app. Maybe it would help to pass parameters like -adce or -globaldce to opt (from llvm). But I can not figure out how I can tell ghc to pass these parameters. Someone knows? Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 11:59 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:26 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: Can you run it in gdb and loock what the backtrace looks like? Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with file. Maybe you have to do something like that to? $ ntoarm-gdb --core=Main.core Main ... copyright and such ... [New pid 14336138 tid 1] warning: .dynamic section for /home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1 is not at the expected address (wrong library or version mismatch?) Program terminated with signal 11, Segmentation fault. #0 0x08402000 in ?? () (gdb) bt #0 0x08402000 in ?? () #1 0x082de978 in stg_ap_p_fast () #2 0x082de978 in stg_ap_p_fast () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Sorry, I can not help. All I can do is point you here: http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode?redirectedfrom=DebuggingGhcCrashes Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Size of crosscompiled exectuable
Hey, A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Why is this? Can I do something about it? Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc passing -undef to preprocessor and thereby eliminating OS specific defines
Hey, I am trying to adapt some code in the libraries when compiling for android (i.E. because some things are different on android to other posix systems). So in C code I would just do #ifdef __ANDROID__. While in the *.h and *.c files it seems to work, it does not work in *.hs files. I noted that the preprocessor is run like this: arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector -DTABLES_NEXT_TO_CODE The -undef parameter is causing the __ANDROID__ define to be removed. Does it make sense to pass -undef to the preprocessor? Any other Ideas how I could adapt the code for android? Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
Hey, For me thinks have changed. With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! I have not tested much, but Hello World works. Regards, Nathan On 01/14/2013 06:15 PM, Nathan Hüsken wrote: In a different thread (Error building ghc on raspberry pi): On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...) I did eventually finish building stage2, but the final executable segfaulted on start. I haven't investigated much why that happened, the days it takes to rebuild it just made me give up. Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work. So I wonder if it is a general arm problem or has to do with android. Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 03:58 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. Did you have to hack the source ala http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch ? Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs Stephen Blackheath found that out, see here: http://www.haskell.org/pipermail/iphone/2013-January/000212.html From that post, it seems like llvm-3.0 might also work? At the time of that post, ghc did not compile with 3.0 or 3.2. I have sticked to 3.2, and ghc compiles with it now. I do not know about 3.0. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 04:50 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 04:28 PM, Stephen Paul Weber wrote: Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch ? Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours... How the heck am I supposed to figure out what that string should be? :( Do you mean the data layout? Actually, I have to admit I just copied it from arm linux. That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about. I ... it just worked :). I passed --enable-unregistered to configure and that did the trick. During building it always said via-C, but it worked. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 05:04 PM, Karel Gardas wrote: On 01/24/13 04:50 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 04:28 PM, Stephen Paul Weber wrote: Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch ? Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours... IIRC it's more about optimization, i.e. proper data type alignment. How the heck am I supposed to figure out what that string should be? :( Described here: http://llvm.org/docs/LangRef.html#data-layout -- for LLVM 3.3. General rule, I would start with what Linux requires and check from that. That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about. IMHO Nathan is using registerised build. Nathan correct me please if I'm wrong as I'd like to also give your Android work a try in the future (being Android user myself...) Yes, that is correct. registerised with llvm 3.2. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 05:51 PM, Stephen Paul Weber wrote: (...) So... it can't find memcpy for some reason? I'm about to try with llvm-3.2 to see if that's different. I had similar problems with mkfifo. I believe the reason was, that in the android nkd mkfifo is inlined. The solution for me was to wrap mkfifo (in a function I called __mkfifo) and used that one from the ffi instead. But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 07:00 PM, Stephen Paul Weber wrote: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: Doing a registered build with llvm-3.0 I eventually get: In function `c58Y_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to `__aeabi_memcpy' collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2 This is purely linker issue. Somehow you link with different set of libraries probably. Anyway it looks like: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html -- this function is part of common ARM EABI so it should be implemented by your C compiler tool-chain. You just need to find out where it is and how you may use it. So, not sure on the right solution, but when I add -lcapsthen the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2 :( Can you run it in gdb and loock what the backtrace looks like? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
On 01/24/2013 07:26 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:00 PM, Stephen Paul Weber wrote: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcapsthen the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2 :( Can you run it in gdb and loock what the backtrace looks like? [New pid 14037182 tid 1] Program terminated with signal 11, Segmentation fault. #0 0x08502000 in ?? () (gdb) bt #0 0x08502000 in ?? () #1 0x082ce4c4 in ?? () #2 0x082ce4c4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) Not very informative :). Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with file. Maybe you have to do something like that to? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
I got this error too. In my case it helped to install llvm-3.0 next to llvm (in ubuntu the executables are than called llc-3.0 and opt-3.0). I believe this error just came in the first phase, and was caused by the preinstalled ghc-7.4.2. But I am not sure. On 01/19/2013 07:45 AM, Stephen Paul Weber wrote: Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? Just finally got a BB10 device set up so I can test my cross-compiler on the ARM I'm about to try a configuration with --enable-unregisterised to see if that helps. I think I can configure it to use unregistered LLVM, so I'm off to try that, but this seems like a bug. Trying that gives me: [ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0 make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 I'm using LLVM 3.1. This errors makes no sense to me, because when I just use quick and not unregistered, it falls back to LLVM and works fine, but now I've selected quick-llvm and unregistered and it can't find it? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
any successfull ghc registerised builds on arm?
In a different thread (Error building ghc on raspberry pi): On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...) I did eventually finish building stage2, but the final executable segfaulted on start. I haven't investigated much why that happened, the days it takes to rebuild it just made me give up. Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work. So I wonder if it is a general arm problem or has to do with android. Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building on android - compiled program segfaults
There is some more success :). When I do an unregisterised build, it works without segfault. On 01/13/2013 11:16 AM, Bernhard Urban wrote: Hi Nathan, On Fri, Jan 11, 2013 at 12:36 PM, Nathan Hüsken nathan.hues...@posteo.de wrote: I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Great news! Can you describe how you managed to build it and which environment you use? I am on ubuntu 64 bit. I am planing to share the information in a blog post, but I will wait if I (or someone else) gets the registerised build to work. I made a short writedown of the steps it took here: https://github.com/RudolfVonKrugstein/jshaskell-blog/blob/master/android_ghc/android_ghc.md Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building on android - compiled program segfaults
Mmh, that does not seem to work. (gdb) strace warning: Couldn't determine the static tracepoint marker to probe Static tracepoint 1 at 0x3f0588 On 01/13/2013 12:56 PM, Conrad Parker wrote: On 11 January 2013 19:36, Nathan Hüsken nathan.hues...@posteo.de wrote: Hi, I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Now using inplace/bin/ghc-stage1 -dcore-lint -debug I compiler this Main.hs: main = putStrLn Hello, World I get an executable, which I can run on my android device. Unfortantly it segfaults. Running it with ./Main +RTS -DS gives: cap 0: initialised Now I am trying to debug this in gdb. When I try to display the stack (which should be in r13 on arm of I understand correctly, I get); (gdb) p8 $r13 0xbef00a74: 0x0 0xbef00a70: 0x0 0xbef00a6c: 0x3c2e74 0xbef00a68: 0x530350 0xbef00a64: 0x0 0xbef00a60: 0x0 0xbef00a5c: 0x0 0xbef00a58: 0x0 And now I am clueless. So I tried the good old printf debugging in the rts. Using this, I see that it gets before the call to scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). But when I put a printf in the beginning of scheduleWaitThread (in Schedule.c) it is not shown. What else can I do to find out more? can you strace it? Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understand disassemble for segfault on android
Ok, the instruction
ldr r1, [r0, #140] - tso = CurrentTSO
seems the assume that REG_Base is r0 (140 is the offset of the tso in
StgRegTable, to which the REG_Base register should point).
But according to MachRegs.h on arm architecture, REG_Base should be r4.
Ineed, when I do
p *(unsigned int*)($r4+140)
I get (after converting to hex) is:
0x401033C0
looking at the backtrace:
(...)
#3 0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
pcap=0xbe843b6c)
(...)
this is the same address as given to scheduleWaitThread for tso.
So the question is, why is r0 and not r4 used???
Regards,
Nathan
On 01/13/2013 12:10 AM, Nathan Hüsken wrote:
Hey,
I am still investigating the segfaults of the exectuable produced by ghc
to arm-linux-androideabi cross compiler.
I need help. Can someone tell me if my conclusions are correct?
The crash happens here:
Dump of assembler code for function stg_returnToStackTop:
0x003f059c +0: push{r4, lr}
0x003f05a0 +4: sub sp, sp, #16
0x003f05a4 +8: ldr r1, [r0, #140] ; 0x8c
= 0x003f05a8 +12: ldr r12, [r1, #12]
0x003f05ac +16: ldr r1, [r12, #12]
0x003f05b0 +20: mov r2, #0
Since it is in the begining of stg_returnToStackTop, it has to be
LOAD_THREAD_STATE();
I believe the code for this is produced by loadThreadState:
loadThreadState dflags tso stack = do
catAGraphs [
-- tso = CurrentTSO;
mkAssign (CmmLocal tso) stgCurrentTSO,
-- stack = tso-stackobj;
mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg
(CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)),
(...)
So I believe the instruction are mapped like this:
ldr r1, [r0, #140] - tso = CurrentTSO
ldr r12, [r1, #12] - stack = tso-stackobj
If that is true, the loaded tso pointer ([r0, #140]) must be wrong.
When I look at the backtrace at the moment of crash:
#0 0x003f0588 in stg_returnToStackTop ()
#1 0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350)
at rts/Schedule.c:463
#2 0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0)
at rts/Schedule.c:463
#3 0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
pcap=0xbe843b6c)
at rts/Schedule.c:2351
There is a tso value passed to scheduleWaitThread (tso=0x401033c0).
Should be this is the same address, form where the tso is loaded in the
instruction:
ldr r1, [r0, #140] - tso = CurrentTSO
? If so, the value in r0 is way of.
info register
r0 0x3f057c 4130172
r1 0xe24dd010 -498216944
Are my conclusions so far correct, and I have to find out why r0 is
having the wrong value?
Thanks!
Nathan
___
ghc-devs mailing list
ghc-d...@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Understand disassemble for segfault on android
Hey,
I am still investigating the segfaults of the exectuable produced by ghc
to arm-linux-androideabi cross compiler.
I need help. Can someone tell me if my conclusions are correct?
The crash happens here:
Dump of assembler code for function stg_returnToStackTop:
0x003f059c +0: push{r4, lr}
0x003f05a0 +4: sub sp, sp, #16
0x003f05a4 +8: ldr r1, [r0, #140] ; 0x8c
= 0x003f05a8 +12:ldr r12, [r1, #12]
0x003f05ac +16:ldr r1, [r12, #12]
0x003f05b0 +20:mov r2, #0
Since it is in the begining of stg_returnToStackTop, it has to be
LOAD_THREAD_STATE();
I believe the code for this is produced by loadThreadState:
loadThreadState dflags tso stack = do
catAGraphs [
-- tso = CurrentTSO;
mkAssign (CmmLocal tso) stgCurrentTSO,
-- stack = tso-stackobj;
mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg
(CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)),
(...)
So I believe the instruction are mapped like this:
ldr r1, [r0, #140] - tso = CurrentTSO
ldr r12, [r1, #12] - stack = tso-stackobj
If that is true, the loaded tso pointer ([r0, #140]) must be wrong.
When I look at the backtrace at the moment of crash:
#0 0x003f0588 in stg_returnToStackTop ()
#1 0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350)
at rts/Schedule.c:463
#2 0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0)
at rts/Schedule.c:463
#3 0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
pcap=0xbe843b6c)
at rts/Schedule.c:2351
There is a tso value passed to scheduleWaitThread (tso=0x401033c0).
Should be this is the same address, form where the tso is loaded in the
instruction:
ldr r1, [r0, #140] - tso = CurrentTSO
? If so, the value in r0 is way of.
info register
r0 0x3f057c 4130172
r1 0xe24dd010 -498216944
Are my conclusions so far correct, and I have to find out why r0 is
having the wrong value?
Thanks!
Nathan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building on android - compiled program segfaults
Hi, I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Now using inplace/bin/ghc-stage1 -dcore-lint -debug I compiler this Main.hs: main = putStrLn Hello, World I get an executable, which I can run on my android device. Unfortantly it segfaults. Running it with ./Main +RTS -DS gives: cap 0: initialised Now I am trying to debug this in gdb. When I try to display the stack (which should be in r13 on arm of I understand correctly, I get); (gdb) p8 $r13 0xbef00a74: 0x0 0xbef00a70: 0x0 0xbef00a6c: 0x3c2e74 0xbef00a68: 0x530350 0xbef00a64: 0x0 0xbef00a60: 0x0 0xbef00a5c: 0x0 0xbef00a58: 0x0 And now I am clueless. So I tried the good old printf debugging in the rts. Using this, I see that it gets before the call to scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). But when I put a printf in the beginning of scheduleWaitThread (in Schedule.c) it is not shown. What else can I do to find out more? Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Compiling ghcjs
Hi, I hope this is the correct list to ask this question. I am trying to compile the ghcjs compiler. I am on ubuntu 12.04 and have ghc-7.4.1 installed (via apt-get). I am following the instruction I found here: https://github.com/ghcjs/ghcjs The first trouble comes with git pull ghcjs. I get: remote: Counting objects: 42, done. remote: Compressing objects: 100% (9/9), done. remote: Total 26 (delta 22), reused 21 (delta 17) Unpacking objects: 100% (26/26), done. From github.com:ghcjs/packages-Cabal * [new branch] encoding - ghcjs/encoding * [new branch] ghc-7.2- ghcjs/ghc-7.2 * [new branch] ghc-7.4- ghcjs/ghc-7.4 * [new branch] master - ghcjs/master You asked to pull from the remote 'ghcjs', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. So I am doing: git pull ghcjs ghc-7.4 Then git branch ghc-7.4 ghcjs/ghc-7.4 gives me: fatal: A branch named 'ghc-7.4' already exists. And finaly perl boot fails with: Error: libraries/extensible-exceptions/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, PACKAGES line 57. What can I do? Thanks! Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
