> After a day of running gdb in parallel on my MacOS X and Linux [quite
> annoying because of different keyboard layouts ;-) ], I've
> come to the following conclusion:
>
> The entry code for BCOs expects all parameters to be on the
> stack, but
> on non-x86 machines, the stg_ap_*_ret pass parameters to it in
> registers (as for function objects). This leads to frequent
> crashes in GHCi on PowerPC, but not on Intel.
Ach! Good point. I haven't tested the newest GHC on our Sparc yet,
which is why I hadn't noticed this.
> My first attempt at fixing this (by making stg_BCO_entry push the
> parameters onto the stack) is attached below, but I'm not
> committing it
> as I'm not sure it's the right way to do it. Are the stg_ap_*_ret
> functions the only places where a BCO is entered? It might be a nicer
> solution to modify GenApply to pass parameters to BCOs on the stack.
It's not quite right, because there might be other regs in use apart
from the vanilla regs. I think that stg_BCO_entry can only be entered
via the stg_ap_*_ret functions, but we shouldn't rely on this.
The annoying thing is that the code for PAPs is *almost* right (i.e. in
each stg_ap_*_ret, just move the apply_fun label to the PAP case
instead), but it ends up jumping to stg_PAP_entry instead of
stg_BCO_entry. So I've merged these two cases by storing the jump
target in a variable instead. Try the new version and let me know if it
fixes the problem.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
