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