>> The next question is how to implement the undefined instruction >> exception handler. Is 0x00000004 (or optionally 0xFFFF0004) writable (I >> need to write some test code really) from a user program? Assuming it >> is, then it should be reasonably straightforward to write an exception >> handler and to use this to branch to some code to handle the >> un-implemented Java instructions. If it's not possible to write to this >> memory, how do programs like gdb hook exceptions? Have I missed some >> unseen stumbling-block here? > > GDB doesn't handles exceptions because they are mapped as signal at kernel > level. This is a posix abstraction. Unexpected ones are handled as > 'Segmentation Fault'. > > Exceptions must be handled at ring0. You should compile a new kernel. > No idea if is easy to do the same into a kernel module, but you can > directly write assembly in /dev/mem into the interrupt vector and > launch these new syscalls to trigger your snippets. > > I have never hooked an exception on ARM or Linux, so I should probably > need to read more kernel :)
Oh, knew it couldn't be all that easy. Well the old style floating point emulation code used to trap the floating point instructions, so there's code out there. On the other hand, is enough information passed with the signal produced by the kernel to be able to write a handler and successfully return without killing the process? >> I seem to remember seeing a list of those instructions that are handled >> by the hardware, does anyone have a link? (though obviously writing a >> piece of code to interate through and see which cause exceptions is >> quite possible). > > Take a look here: > > http://www.gelato.unsw.edu.au/lxr/source/arch/arm/mm/fault.c > Ah, thanks for that, but I was meaning the Java instructions that are not implemented in hardware (my fault for the poor explanation). The Java hardware stores the top 4 stack entries in registers R0 to R3, and the hardware does the manipulation of these entries (pushing/popping and pulling/pushing those that don't fit to somewhere else). So I was wondering what would happen if any of the non-hardware instructions needed to pop/push to the stack. It may be (hopefully) that none of the non-hardware instructions actually need to access the stack. Oh, I managed to reply to myself last night rather than the list regarding this: > The text says it should run "BXJ R14" which effectively returns control > to the next instruction of the Java program, which is what one would > assume. Fig.3 also shows a check on whether Java hw interpretation is > available, and it is this check that determines whether a normal branch > is made to the address in R12 (to emulate the next instruction) or a > branch to Java to R14 (to continue hw interpretation). This makes > sense, so I think that box 34 is simply wrong. I take it back, the diagram was correct. BXJ should be called with the address of the emulation code (which may or may not need to also be present in R12) and R14 should contain the address of the next Java bytecode. The hardware makes the decision as to whether to do a normal branch to R12 or to enter Java mode and execute the Java instruction at R14. Serves me right for not reading the whole document! Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
