Extended periods of "waking up thread %d on cap %d"

2013-01-25 Thread Ben Gamari 
Recently I've been benchmarking my concurrent Gibbs sampler[1] on a
largish multicore machine. I've been using GHC HEAD due to various
GC-related fixes that are present. One thing that I've noticed in
looking over the event logs is that there are large durations (tens of
milliseconds) when HECs appear to be constantly bombarded with wake-ups
from other capabilities.

In these periods, the eventlog will be filled with blocks of messages
such as this snippet from one benchmark run[2] (long repeated blocks
marked with ellipses, a few irrelevant messages have been omitted yet
not marked, see eventlog for full log),

 28.320958sHEC 7: running thread 293
 ...
 28.391802sHEC 6: running thread 209
 28.392070sHEC 6: waking up thread 284 on cap 7
 28.392302sHEC 6: waking up thread 284 on cap 7
 28.392579sHEC 6: waking up thread 284 on cap 7
 28.392808sHEC 6: waking up thread 284 on cap 7
 .
 .
 .
 28.405971sHEC 16: waking up thread 284 on cap 7
 28.406026sHEC 15: waking up thread 284 on cap 7
 28.406080sHEC 12: waking up thread 284 on cap 7
 28.406091sHEC 23: waking up thread 284 on cap 7
 28.406095sHEC 6: waking up thread 284 on cap 7
 28.406095sHEC 23: waking up thread 284 on cap 7
 28.406225sHEC 16: waking up thread 284 on cap 7
 .
 .
 .
 28.490449sHEC 7: stopping thread 293 (thread yielding)
 28.490454sHEC 7: waking up thread 284 on cap 7
 28.490454sHEC 7: waking up thread 284 on cap 7
 28.490455sHEC 7: waking up thread 284 on cap 7
 28.490456sHEC 7: waking up thread 284 on cap 7
 28.490456sHEC 7: waking up thread 284 on cap 7
 28.490457sHEC 7: waking up thread 284 on cap 7
 28.490458sHEC 7: waking up thread 284 on cap 7
 .
 .
 .
 28.491841sHEC 7: waking up thread 284 on cap 7
 28.491850sHEC 7: migrating thread 284 to cap 0
 28.491968sHEC 7: running thread 293
 .
 .
 .

In other words, it appears that HEC 7 took a vacation of more than a
millisecond as it tried (ultimately unsuccessfully) to wake up thread
284. These blocks are easy to spot in this event log and quite difficult
to explain. In this case I was being silly and spawned a few too many
capabilities (30 capabilities whereas the machine has 24 real cores, 2
threads per core due to hyperthreading; I was running 24 threads).

That being said, even under more reasonable conditions[3] (where I was
running 24 capabilities with 20 threads on the same 24-core machine) I
still see problems waking up. For example, from 32.293455s to 32.327349s
see numerous attempts by many HECs to wake-up thread 517 on cap
12. In this period, cap 12 briefly runs thread 537 (32.326781s)
but while running HEC 17 attempts to wake up 517 again.

All-in-all, something seems a bit strange. Any ideas what might be going
on here?

I've CC'd Edward Yang (who I understand has recently been doing a
rework on the scheduler) and Simon Marlow.

Thanks,

- Ben


[1] https://github.com/bgamari/bayes-stack
[2] http://goldnerlab.physics.umass.edu/~bgamari/Benchmark-wakeup.eventlog
[3] 
http://goldnerlab.physics.umass.edu/~bgamari/Benchmark-wakeup-smaller.eventlog

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of crosscompiled exectuable

2013-01-25 Thread Simon Marlow 

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).

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.


Incidentally, I now have a registerised cross-compiler for Raspberry Pi 
compiling a working hello world :)  (LLVM 3.0, GHC HEAD)


GhcStage2HcOpts= -O0 -fllvm -pgmlc llc-3.0 -pgmlo opt-3.0 -optlc 
-mtriple=arm-linux-gnueabihf -optlc -mattr=+vfp2 -optlc -float-abi=hard
GhcLibHcOpts   = -O -fllvm -pgmlc llc-3.0 -pgmlo opt-3.0 -optlc 
-mtriple=arm-linux-gnueabihf -optlc -mattr=+vfp2 -optlc -float-abi=hard
GhcRtsHcOpts  += -fllvm -pgmlc llc-3.0 -pgmlo opt-3.0 -optlc 
-mtriple=arm-linux-gnueabihf -optlc -mattr=+vfp2 -optlc -float-abi=hard


Nice work everyone.

Cheers,
Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of crosscompiled exectuable

2013-01-25 Thread Simon Marlow 

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).

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.


Cheers,
Simon



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Fastest way to reload module with GHC API

2013-01-25 Thread Simon Marlow 
Has the file's modification time changed?  If you're doing this very 
quickly (within 1 second) then you might run into this:


http://hackage.haskell.org/trac/ghc/ticket/7473

Cheers,
Simon

On 25/01/13 16:02, JP Moresmau wrote:

When I do that (only adding the target once and just doing load after
the file has changed) the changes in the file are not taken into account
(getNamesInScope for example doesn't give me the name of a type added
inside the file). I probably have my stupid hat on (friday
afternoon...), but when I do remove/load in between it works...

Thanks


On Fri, Jan 25, 2013 at 4:33 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:

On 25/01/13 14:30, JP Moresmau wrote:

Hello, I just want to be sure of what's the fastest way to reload a
module with the GHC API.
I have a file whose path is fp
I load the module with:
addTarget Target { targetId = TargetFile fp Nothing,
targetAllowObjCode
= True, targetContents = Nothing }
Then I load the module
load LoadAllTargets
And when I want to reload the module (the contents of fp have
changed) I do:
removeTarget (TargetFile fp Nothing)
load LoadAllTargets
and then I rerun my initial code (addTarget, load)


You should be able to just invoke 'load LoadAllTargets' and omit the
intermediate remove/load step.  Or is there a reason you want to
remove the target?

Cheers,
 Simon




--
JP Moresmau
http://jpmoresmau.blogspot.com/



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Fastest way to reload module with GHC API

2013-01-25 Thread JP Moresmau 
When I do that (only adding the target once and just doing load after the
file has changed) the changes in the file are not taken into account
(getNamesInScope for example doesn't give me the name of a type added
inside the file). I probably have my stupid hat on (friday afternoon...),
but when I do remove/load in between it works...

Thanks


On Fri, Jan 25, 2013 at 4:33 PM, Simon Marlow  wrote:

> On 25/01/13 14:30, JP Moresmau wrote:
>
>> Hello, I just want to be sure of what's the fastest way to reload a
>> module with the GHC API.
>> I have a file whose path is fp
>> I load the module with:
>> addTarget Target { targetId = TargetFile fp Nothing, targetAllowObjCode
>> = True, targetContents = Nothing }
>> Then I load the module
>> load LoadAllTargets
>> And when I want to reload the module (the contents of fp have changed) I
>> do:
>> removeTarget (TargetFile fp Nothing)
>> load LoadAllTargets
>> and then I rerun my initial code (addTarget, load)
>>
>
> You should be able to just invoke 'load LoadAllTargets' and omit the
> intermediate remove/load step.  Or is there a reason you want to remove the
> target?
>
> Cheers,
> Simon
>
>


-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of crosscompiled exectuable

2013-01-25 Thread Stephen Paul Weber 

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).


The problem is not the size, but the size ratio.

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of crosscompiled exectuable

2013-01-25 Thread Brandon Allbery 
On Fri, Jan 25, 2013 at 8:58 AM, 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.
>

If I had to guess, libc is linked dynamically on Ubuntu (Linux really wants
this) but statically when cross-compiled.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of crosscompiled exectuable

2013-01-25 Thread Simon Marlow 

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.


GHC statically links all its libraries by default.  If you want a 
dynamically linked executable, use -dynamic (ensure you have the dynamic 
libraries built and/or installed though).



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?


Static linking is useful when cross compiling, because it means you can 
just copy the binary over to the target system and run it.


Cheers,
Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Fastest way to reload module with GHC API

2013-01-25 Thread Simon Marlow 

On 25/01/13 14:30, JP Moresmau wrote:

Hello, I just want to be sure of what's the fastest way to reload a
module with the GHC API.
I have a file whose path is fp
I load the module with:
addTarget Target { targetId = TargetFile fp Nothing, targetAllowObjCode
= True, targetContents = Nothing }
Then I load the module
load LoadAllTargets
And when I want to reload the module (the contents of fp have changed) I do:
removeTarget (TargetFile fp Nothing)
load LoadAllTargets
and then I rerun my initial code (addTarget, load)


You should be able to just invoke 'load LoadAllTargets' and omit the 
intermediate remove/load step.  Or is there a reason you want to remove 
the target?


Cheers,
Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: data kinds

2013-01-25 Thread José Pedro Magalhães 
See http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData


Cheers,
Pedro

On Fri, Jan 25, 2013 at 3:19 PM, Ross Paterson  wrote:

> GHC implements data kinds by promoting data declarations of a certain
> restricted form, but I wonder if it would be better to have a special
> syntax for kind definitions, say
>
>   data kind Nat = Zero | Succ Nat
>
> At the moment, things get promoted whether you need them or not, and
> if you've made some mistake that makes your definition non-promotable
> you don't find out until you try to use it.
>
> More importantly, a separate form for kinds would allow one to use
> existing kinds, i.e. *, in definitions of new kinds.
>
> ___
> 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

data kinds

2013-01-25 Thread Ross Paterson 
GHC implements data kinds by promoting data declarations of a certain
restricted form, but I wonder if it would be better to have a special
syntax for kind definitions, say

  data kind Nat = Zero | Succ Nat

At the moment, things get promoted whether you need them or not, and
if you've made some mistake that makes your definition non-promotable
you don't find out until you try to use it.

More importantly, a separate form for kinds would allow one to use
existing kinds, i.e. *, in definitions of new kinds.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Fastest way to reload module with GHC API

2013-01-25 Thread JP Moresmau 
Hello, I just want to be sure of what's the fastest way to reload a module
with the GHC API.
I have a file whose path is fp
I load the module with:
addTarget Target { targetId = TargetFile fp Nothing, targetAllowObjCode =
True, targetContents = Nothing }
Then I load the module
load LoadAllTargets
And when I want to reload the module (the contents of fp have changed) I do:
removeTarget (TargetFile fp Nothing)
load LoadAllTargets
and then I rerun my initial code (addTarget, load)

This works well, I don't get any errors about duplicates, the information I
extract from the module is updated properly. But is it the most efficient,
or can I achieve the same thing faster (I'm looking at improving the
performance of my BuildWrapper code and by consequence of EclipseFP)?

Thanks!

-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Size of crosscompiled exectuable

2013-01-25 Thread Nathan Hüsken 
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

Re: Error building ghc on raspberry pi.

2013-01-25 Thread Neil Davies 
That's good to hear - we've got AFS and the dev-RPi's are using it…

Neil
On 25 Jan 2013, at 12:20, Simon Marlow  wrote:

> On 25/01/13 11:23, Neil Davies wrote:
>> Simon
>> 
>> Looking at the wiki - I take it that the stage 1 compiler can now be used as 
>> "native" compiler on the RPi? (last line of entry)?
> 
> Do you mean the stage 2 compiler?  If so yes - in principle.  But in practice 
> the binary-dist machinery doesn't work properly for cross-compilers yet, so 
> it's hard to install it on the RPi.  If you have a shared network filesystem 
> then perhaps 'make install' works, or if you copy the build tree to your RPi 
> at the same location as your build machine, then maybe it will work.
> 
> Cheers,
>   Simon
> 
> 
> 
>> Neil
>> 
>> On 25 Jan 2013, at 10:46, Simon Marlow  wrote:
>> 
>>> FYI, I created a wiki page for cross-compiling to Raspberry Pi:
>>> 
>>> http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi
>>> 
>>> I have an unregisterised build using LLVM working now (it just worked, 
>>> modulo the tiny fix for #7622).
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> On 21/01/13 16:06, Karel Gardas wrote:
 On 01/21/13 04:43 PM, rocon...@theorem.ca wrote:
> So the binary-dist has a settings.in file. It is the configure step in
> the binary-dist that generates the corrupt settings file.
 
 Perhaps you've forgotten to regenerate bin-dist configure as you did
 with build tree configure after applying my patch?
 
> I'll try to poke around to see where and why the stage2 compiler and the
> binary-dist compiler differ.
 
 Please post your findings here, I'm really curious what is the culprit
 here...
 
 Karel
 
 
 
 ___
 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
>> 
> 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHCJS, JavaScript, cross-platform typechecking with the GHC API and primops

2013-01-25 Thread Luite Stegeman 
hi all,

I've been working on GHCJS [1] for a while and am trying to get it to
work on 64 bit GHC.

A quick background: GHCJS uses the GHC API to generate STG, which it
then translates to JavaScript. It uses slightly patched versions of
the integer-gmp, base and ghc-prim libraries and supports many GHC
features, including arrays and threading.

All JavaScript numbers are essentially double precision floating
point. With some tricks (using bitwise operators) it's possible to get
reasonable 32 bit integer emulation out of it, but emulating 64 bit
integers would be very slow. Therefore, if we compile Haskell to
JavaScript, it should really be treated as a 32 bit target.

Now this is a problem, with GHC 7.6 and lower, generated STG depended
on the word size of the host, so it was simply impossible to do this
with a 64 bit host. In HEAD, wORD_SIZE_IN_BITS is now in DynFlags, so
I decided to have another go. I'm aiming for the following procedure
to install GHCJS and build a package:

# cabal install ghcjs  -- installs `ghcjs`, `ghcjs-boot`, `ghcjs-pkg`,
`ghcjs-cabal`
# ghcjs-boot -- build ghc-prim, integer-gmp, base for
GHCJS and register them in its package db
# ghcjs-cabal install myPackage -- cabal wrapper that uses ghcjs instead of ghc

GHCJS instructs the GHC API to build 32 bit code [2] and sets
preprocessor definitions so that libraries also expect 32 bit code.
Library patches include PrimOpWrappers in ghc-prim, which is generated
from the 32 bit primops. But here's the problem: When typechecking
PrimOpWrappers, the GHC API appears to use its own built-in types for
everything in GHC.Prim, and there are differences between 32 bit and
64 bit (for example popCnt64# :: Word64# -> Word# on 32 bit, :: Word#
-> Word# on 64), so you get lots of errors.

Now I'm wondering, is there a way around this, or would it be
reasonable to modify GHC to somehow have the primop types in DynFlags,
instead of them being hardcoded in the compiler?

luite

[1] https://github.com/ghcjs/ghcjs (I'm mostly working in the Gen2
branch, an experimental faster code generator)
[2] https://github.com/ghcjs/ghcjs/blob/gen2/src-bin/Compiler/Main.hs#L345

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

2013-01-25 Thread Simon Marlow 

On 25/01/13 11:23, Neil Davies wrote:

Simon

Looking at the wiki - I take it that the stage 1 compiler can now be used as 
"native" compiler on the RPi? (last line of entry)?


Do you mean the stage 2 compiler?  If so yes - in principle.  But in 
practice the binary-dist machinery doesn't work properly for 
cross-compilers yet, so it's hard to install it on the RPi.  If you have 
a shared network filesystem then perhaps 'make install' works, or if you 
copy the build tree to your RPi at the same location as your build 
machine, then maybe it will work.


Cheers,
Simon




Neil

On 25 Jan 2013, at 10:46, Simon Marlow  wrote:


FYI, I created a wiki page for cross-compiling to Raspberry Pi:

http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi

I have an unregisterised build using LLVM working now (it just worked, modulo 
the tiny fix for #7622).

Cheers,
Simon

On 21/01/13 16:06, Karel Gardas wrote:

On 01/21/13 04:43 PM, rocon...@theorem.ca wrote:

So the binary-dist has a settings.in file. It is the configure step in
the binary-dist that generates the corrupt settings file.


Perhaps you've forgotten to regenerate bin-dist configure as you did
with build tree configure after applying my patch?


I'll try to poke around to see where and why the stage2 compiler and the
binary-dist compiler differ.


Please post your findings here, I'm really curious what is the culprit
here...

Karel



___
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





___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

2013-01-25 Thread Neil Davies 
Simon

Looking at the wiki - I take it that the stage 1 compiler can now be used as 
"native" compiler on the RPi? (last line of entry)?

Neil

On 25 Jan 2013, at 10:46, Simon Marlow  wrote:

> FYI, I created a wiki page for cross-compiling to Raspberry Pi:
> 
> http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi
> 
> I have an unregisterised build using LLVM working now (it just worked, modulo 
> the tiny fix for #7622).
> 
> Cheers,
>   Simon
> 
> On 21/01/13 16:06, Karel Gardas wrote:
>> On 01/21/13 04:43 PM, rocon...@theorem.ca wrote:
>>> So the binary-dist has a settings.in file. It is the configure step in
>>> the binary-dist that generates the corrupt settings file.
>> 
>> Perhaps you've forgotten to regenerate bin-dist configure as you did
>> with build tree configure after applying my patch?
>> 
>>> I'll try to poke around to see where and why the stage2 compiler and the
>>> binary-dist compiler differ.
>> 
>> Please post your findings here, I'm really curious what is the culprit
>> here...
>> 
>> Karel
>> 
>> 
>> 
>> ___
>> 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


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

2013-01-25 Thread Simon Marlow 

FYI, I created a wiki page for cross-compiling to Raspberry Pi:

http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi

I have an unregisterised build using LLVM working now (it just worked, 
modulo the tiny fix for #7622).


Cheers,
Simon

On 21/01/13 16:06, Karel Gardas wrote:

On 01/21/13 04:43 PM, rocon...@theorem.ca wrote:

So the binary-dist has a settings.in file. It is the configure step in
the binary-dist that generates the corrupt settings file.


Perhaps you've forgotten to regenerate bin-dist configure as you did
with build tree configure after applying my patch?


I'll try to poke around to see where and why the stage2 compiler and the
binary-dist compiler differ.


Please post your findings here, I'm really curious what is the culprit
here...

Karel



___
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?

2013-01-25 Thread Simon Marlow 

On 24/01/13 16:58, Nathan Hüsken wrote:

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.



?


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.


You're not using LLVM, due to #7622.  I'll push the trivial patch to fix 
that as soon as it has validated here.


Cheers,
Simon



___
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?

2013-01-25 Thread Nathan Hüsken 
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