On Tue, Sep 10, 2013 at 06:35:56PM +0200, Joachim Breitner wrote: > Am Montag, den 09.09.2013, 14:37 +0200 schrieb Thomas Preud'homme: > > please reenable ghci on arm as it prevents many package from building. I > > improved on the patch proposed upstream and it works on porterbox. Maybe > > you could give it a try in experimental. See the patch in the attached > > file. > > you looked into that issue last. Can you evaluate that patch?
Thanks for looking into this further. I think that inlining the cache flush will mean that every chunk of bytecode assembled by the interpreter will flush the instruction cache every time it's called. It will be even slower than it's necessary for it to be. That in itself would probably be tolerable. Much more importantly, though, this patch misses the point of flushing the instruction cache. The point is that we need to flush the cache in order for the processor to reliably read back the code that we just wrote out; flushing the cache in that very code is not a viable approach to that, because the cache-flushing code itself might not be read. So I'm afraid I don't think this is going to work properly. It might work some of the time, of course, depending on cache locality, but I can't see how it would work reliably. Other things we need to do after this is fixed: We should include my R_ARM_V4BX relocation patch too in order to support armel. See: http://lists.debian.org/debian-haskell/2013/05/msg00054.html I would suggest testing whether some reasonable stack actually builds with this; I don't know how much testing you did but it e.g. isn't enough to just start ghci. Perhaps see if haskell-conduit runs its doctests successfully during build. Sorry, -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
