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

[Martin Stein]

Hi Josef,

El 25/01/18 a las 18:28, Stark, Josef escribió:
>> As you should be the parent of the traced component, you can intercept
>> the CPU session and remember all thread capabilities created by the
>> component. On a fault you iterate through all threads to select those
>> that are currently in a page fault. A good example for this is the GDB
>> monitor [1]. 
> Ok, so far, so good, I could successfully get the threads within my
> target process and indeed access the correct instruction pointer.
> But the next problem is that Thread_state::unresolved_page_fault
> for me always 0 is, for all threads (I provoked a pagefault by detaching
> the dataspace), so I can't filter out the faulter(s). Do you have a clue?
> As long as I don't attach a dataspace at the corresponding address,
> it should indeed be an unresolved page fault, or am I wrong here?

At least in the current Genode release, the 'unresolved_page_fault' flag
is set in [1] hence in [2] when giving up resolving the fault in core
and consigning to the userland handler. I assume you're using a patched
fork of an older Genode version so maybe things are different in your
case. However, have you had a look ad the GDB monitor?

>> Now you want to select from the remaining threads those
>> that are in a fault on your specific address. This can't be done with
>> the current Genode API, but an easy way to achieve it would be to expand
>> the Cpu_state [2] to deliver also the value of the ARM Data Fault
>> Address Register or DFAR when calling Cpu_thread_client::state (make
>> sure to update the dfar member in [4] as is done in [3]).
> Good. I'm using Fiasco.OC though, so I'll have to figure out how to
> do this there. Writing a custom kernel function making the assembler call
> copied from Genode just froze the VM, but I already asked the Fiasco.OC
> people for help.
>> Then, you would have to continue execution of
>> the thread. Unfortunately, this is normally done automatically by
>> Genodes Core when it sees a new mapping that matches the fault address.
>> You don't want to do such a mapping, but there is no explicit "resume
>> this faulter". So, you have might add such an RPC call [5] and its back
>> end [6] to the RM interface. This shouldn't be much invasive.
> At least this seems to work.
Could you please explain in more detail what you mean with that? How do
you get the faulter to continue execution without attaching a dataspace?

Cheers,
Martin

[1]
base-foc/src/core/pager_object.cc

[2]
base/src/core/region_map_component.cc:207