Hi, In Linux you can read some portions of the process memory from procfs, that should be faster than reading 4byte chunks with ptrace(). I wrote a function to read memory from procfs and switching to (slower) ptrace() if reading from procfs failed. Pancake included that code in radare a long time ago IIRC.
I think a cache could be implemented to do fast reads/writes while the whole debugged program is stopped, each time any thread of the app continues the cache should be flushed. On 11 May 2010 09:31, mobi phil <[email protected]> wrote: > Hello, > > My original emails did not reach the list, so I started a private > discussion with pancake. > > It was very strange for me that searching for was much slower when in > debug mode. Did not take me long to understand the obvious, that when > in debug mode, you have to access the memory of the process through > ptrace, that makes it slow. > > I asked pancake, if stuff should not be cached, and he told me that > there would be already some cache mechanism in place, but I should > propose the discussion about the topic on the list. > > So the goal of this thread is to collect use cases/ideas/etc., about > caching the traced process memory inside radare2, for speeding up > operations like search. > > So one of the key questions would be: > * what kind of operations are invalidating the cache? > * ??? :) > > > -- > rgrds, > mobi phil > > being mobile, but including technology > http://mobiphil.com > _______________________________________________ > radare mailing list > [email protected] > http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org > -- There is a crack, a crack in everything. That's how the wine gets in. _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
