> In Linux you can read some portions of the process memory from procfs, > that should be faster than reading 4byte chunks with ptrace(). That is a cool idea... I did not think about that... > I wrote > a function to read memory from procfs and switching to (slower) > ptrace() if reading from procfs failed. when would reading from procfs fail?
> 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. Well, for sure the read only areas can be kept... On the other hand always flushing is not necessarily a good idea to have it the "only strategy". Imagine that you are debugging a huge application, where in avarage only 1% of the memory is modified. I am working for example on a project that has 1GB of database data cached in memory. The typical use case is to query the database, so probably 10BMB of data is really changed. Now if cache would be flushed at each debug step, would have to wait to reload. In such a situation, one would prefer to work with a bit "dirty" cache, but to be aware that it is a bit dirty. But it would help to get the job done! If the user concludes that the dirty cache might hide the useful info, he/she can decide to reload the "clean" image. -- 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
