> The thing is that proc/pid/mem is only accessible by the own process > and their childs. this is why you can only use this when forking, or > ptracing a process. AFAIK in solaris this is not in this way.
bit confusing ... in case of a debugger, we are interested to see the proc/pid/mem of the debugged process, which is the child process.. you said proc/pid/mem is accessible by the owner process and their children. nevertheless just to make it clear for myself, I wrote a little test. On linux both child and parent can see it's parent or child proc/pid/mem.. probably that is what you intended to say.. > The patch adds an eval variable named 'dbg.procpidmem' that enables > this mode when setting it to 'true' or '1'. > I have performed a simple benchmark and it results in 25% faster executions. > It doesnt seems to be any specific lag for memory reads now. (when comparing > no reading (return0) or procpidmem readings is near 0 the difference of time. is the search 25% faster? If you mean the search... Hm... would have expected much more.. would have expected the same search speed as by not debbuged process... I will try it myself.. did you mmap /proc/pid/mem into the debuggers memory? Or you are reading the file into memory? Is it always 25%? or second run is faster? > So it seems like a good solution :) > > Can somebody check in which other OS do the proc/pid/mem trick works? > It is mandatory to remove the #if __linux__ check in debug_os_read_at() > > I should port this IO backend to radare2. > > Another trick you can use to do faster searches in memory is by making > the block size bigger: will try it out soon.. 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
