On 12 May 2010 05:00, mobi phil <[email protected]> wrote: >> 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?
I don't know why (this was a long time ago), but reading some addresses from /proc/[pid]/mem falied and with ptrace() not. Maybe you could do some tests (could be a bug and is fixed now). > >> 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. In that case you need to keep track of memory changes (maybe hooking mprotect() and mmap()/munmap()/etc), you can trust in the actual protections of the memory. On the other hand you don't need to cache the whole mem, you could use a small cache and do caching on demand so you wont have problems with huge applications. I think not syncing the cache contents always could lead to confusion nd problems to the user. > > > > > -- > 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
