Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by RoboTux): Replying to [comment:6 cjwatson]:
It will be called every time one of the generated chunks of code is
called, so I would expect it to be suboptimal, yes. That in itself might 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.
Oh, I didn't realize this was the generated code. I don't know if it's because of the language but I can't make much sense of what the code is doing. I assumed this code was some jit compiler and that the jump was executed when a function has just been compiled in order to actually call that function. If it's part of the generated function indeed it's very suboptimal and won't work as you very well explained. My apologize but I don't think I can bring this further without investing quite some time to understand the code. Thanks for being so quick in looking at the patch. Best regards. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7794#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC