The next question is how to implement the undefined instruction
exception handler. Is 0x0004 (or optionally 0x0004) 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
