On 05/13/10 11:36, mobi phil wrote:
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..
I tried to say that quite clear, procpidmem can only be used by
- process itself
- any parent process
- any process that ptrace it
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?
running a whole execution with random memory reads it results in 25%
faster execution, for searching it would be MUCH faster, because it
is not doing any code analysis or so, just reading and searching. This is..
about 90% performance upgrade in search? can you check if its better now?
My benchmark was like that:
time cat test1 | radare -nd ls
time cat test1 | radare -e dbg.procpidmem=1 -nd ls
2nd execution result 25% faster. By using the ?t command you can calculate
the exeuction time of a specific radare command. Try that:
?t/x90389289498489
0.102934 # result time in seconds
--pancake
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
