Memory write tracing/logging of an application / Watchpoints in Genode/Fiasco.OC

Josef Stark j.stark at ...256...
Thu Feb 8 14:58:20 CET 2018

Hi Martin,

> No, continue_after_resolved_fault DOES continue execution (although the
> IP isn't yet the one you need), what I meant is that you can't do this
> in vanilla Genode from userland (not core) without attaching an
> appropriate dataspace. So, you have already extended the RM session by
> an RPC that triggers the core-internal 'continue_after_resolved_fault' ?
> I think this is the best way to do it in your situation.
Yes, this works.
Currently I'm getting the thread state of the faulting thread, increase
the IP by one instruction, and continue the thread. (The instruction
emulation is missing, but the rest looks like it works.)
My current problem is, as explained in the other mail, that I don't know
how to find the memory / the instruction that is pointed to by the IP; I
would like to do it without using imprints. I am the parent of the
target (and it is the only child) and I can access its sessions. But I
don't know where to look for this memory. Once I have the instruction, I
could emulate it.

Another question of the other mail I could answer myself:
> Another thing that I don't completely understand: The pagefault report 
> includes the memory address where the pagefault occured. I can 
> successfully find the corresponding data space. Experimenting a bit 
> showed me that the reported address seems to be 8-Byte-aligned. (Because 
> incrementing the accessed address in the test application byte by byte 
> only results in an 8-byte jump of the reported address 'state.addr' 
> every 8 bytes. Inside an 8-byte group it stays the same.)
> But how can I find out which of the 8 byte(s) was actually accessed? 
> Especially considering that single-byte access doesn't have to be 
> aligned. I think that for your emulator this information was not 
> necessary, so [1] doesn't provide it. But is it even contained in the 
> instruction?
After peeking into a disassembly, it looks like the second half of the
instruction contains the exact address, which now seems logical to me as
the processor somehow needs to now what exactly should be read/written.

So the missing piece of the puzzle is getting the instruction.
Any hint/idea?

Thanks so far and best regards,

[1] os/src/vinit/arm_v7a/instruction.h: load_store()

More information about the users mailing list