The main reason of the slow debugging in r1 is r1 itself, not ptrace at all. utrace doesnt comes with the standard kernel, but i'm sure it will be a faster, because 4byte reading per syscall is ridiculous.
In fact the ptrace interface of some BSDs allow bigger reads. About utrace().. i have never tested it, just read about it, and surely looks interesting, but if I have to patch the kernel to use it..it doesnt looks that useful to me because you usually are forced to debug a process on a specific device or server where you dont have access. All the ptrace() antidebug tricks should not be catched using utrace().. Feel free to write the patch adding support for utrace(), i will not care until it gets in the kernel mainstream. On 05/11/10 14:32, mobi phil wrote:
If I understand well radare is using ptrace. Did you think about advantages offered by utrace? I know you need some kernel level extension to make utrace usable for something like radare... but probably several tracing operations would become much much faster, isnt' it 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
_______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
