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

[Stark, Josef]

Hello Martin,

> 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?
Yes, I've seen in your referenced code how GDB monitor uses this flag.
We're using Genode 16.08, but I can't build the gdb_monitor.run sample,
neither in the vanilla 16.08 nor in our patched version:
"cp: cannot stat 'bin/ld.lib.so': No such file or directory".
So next I'll look into how it's handled on newer versions.

Anyway, I tried to read the DFAR register as you recommended, but it
seems I didn't quite understand what you meant, as an L4 hacker
responded to me in [3] that DFAR/DFSR registers are non-thread-specific
CPU registers, and thus cannot be used to differentiate between the
threads like I tried.

For now, however, I managed to pass the IP via the pagefault report
to the fault handler and can identify the corresponding thread with
it. But I guess that there could be some corner case where two
threads try to access different addresses from the same instruction,
so I might still look into how to do this using DFAR.

> How do you get the faulter to continue execution without 
> attaching a dataspace?
By calling faulter->continue_after_resolved_fault().
You're completely right, it doesn't really continue execution
as I haven't increased the instruction pointer yet, nor did
I attach the dataspace. But it faults again at the same spot, which
shows me that it *would* work if I had emulated the 
instruction and increased the IP.

Thank you.
Josef

[1] base-foc/src/core/pager_object.cc
[2] base/src/core/region_map_component.cc:207
[3] http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008205.html