Hi Norman, Thank you for the information. This optimization seems very important, I'm willing to follow your work. But I'm afraid I do not fully understand how the entire system working. Where can I get some detailed documentations about how does gdb_monitor work and how does fiasco.OC or Genode map memory for each app? I have been read several docs on the Genode website but still puzzled.
Regards keqin
On ÐÇÆÚ¶þ, ËÄÔÂ 23, 2013 5:47 pm, Norman Feske wrote: -----------------------------------------------------------------------------------
----------------------------------------------------------------------------------- Hi Keqin,
You are right. It works. But sometimes it is slow, I guess there also has someinformation mess up the GDB protocal. Thank you very much.
congratulations that you got it working!
Regarding the slowness, I can partially explain the current state. The main reason lies in the way how GDB monitor peeks and pokes in the target's address space. For each individual memory access, we traverse the target's memory-mapping structures, locally map the corresponding memory into the GDB monitor's address space, perform the access, and revert the mapping. When doing a debug operation such as a backtrace or memory dump, this sequence is performed over and over again. Consequently a lot of superfluous (and costly) map and unmap operations are performed. Obviously, there is the opportunity to optimize those memory accesses by the means of caching. I actually started to implement this optimization via a so-called 'Memory_model' in GDB monitor:
https://github.com/genodelabs/genode/blob/master/ports/src/app/gdb_monitor/g...
However, the implementation is not complete, yet. I.e., the cache gets not flushed when needed, which leads to coherency problems. For this reason, I have set NUM_MAPPED_REGIONS to just 1, effectively disabling the optimization. If you like to pick up the work where I left, you are more than welcome to increase the value and try to fix the remaining inconsistency issues. ;-)
Cheers Norman