On 05/12/10 13:26, mobi phil wrote:
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
yep, r1 is only for bugfixing
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.
that's good. ptrace is definitevly quite bad designed,...in fact some
architectures
uses different argument order depending on type of call and things like this
which is pretty ugly (only in linux). on BSD you sometimes miss some
call types
like CONTSC or CONTFORK..so it's not really a standard .. and under solaris
you have to use different methods to retrieve process status (regs..), read
memory, control process, etc.. well..and same for plan9..so certainly ptrace
is weird and not standard at all but its enought portable and simple to make
it work on a wide variety of OSs without having to hack too far.
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!
yes! if utrace is going to be in upstream i'll be happy to do it when
most of
distros use it in their kernels. I dont want to spend time preparing my
system to do something that doesnt exist* yet :P
I will be happy to add utrace() support to radare for linux..and i would
prefer to have this as an option, not mandatory, so you can debug a process
using ptrace or utrace depending on your needs.
linux must die. long life plan9
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.
i fully agree with you, but the debugging architecture in r2 is not yet
fully implemented, but works for most basic things, so you should be
able to check the code and ping me for any question you have.
But I would prefer to wait utrace() gets mainstream, things can change
and is better not to repeat the work twice.
--pancake
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
