> The main reason of the slow debugging in r1 is r1 itself, not > ptrace at all. ok, so I assume things will be improved in r2
> utrace doesnt comes with the standard kernel, > but i'm sure it will be a faster, because 4byte reading per > syscall is ridiculous. there is enough pressure, so I think utrace will go mainstream soon. However as it is I am affraid cannot be used easily for debugging. I think several tool writers should coordinate for utrace extension. Unique view, simple extensions have higher chance to go mainstream. One of the projects that already wrote utrace extensions is called umview. They work on user space virtualisation ideas. > 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. I agree... but look into the future, be prepared. There are tons of papers and discussions against ptrace. Ptrace is history... sthg new is needed. Lot of new things are needed, otherwise linux is going to die! > 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. I will never do anything for any project without complete agreement of the main developer, and not before there will be a clear view of how to do things inside the linux kernel community. 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
