utrace/ptrace status update

[Elena Zannoni]

Can we get these two new people from Redhat posting to this list as they 
make progress on utrace? There is nothing visible from outside, really.
The list has been quite for 1.5 months, if you don't count the annoying 
spam.
What is the plan of integrating with upstream kernel?
What are the plans for gdb starting to use this new stuff? I doubt that 
kernel people will accept things until there is a legitimate user.

elena


Roland McGrath wrote:
> I've been working for a while on several bugs that are regressions of
> ptrace behavior in the latest utrace branch code.  These are all now
> represented in the ptrace-tests suite; Denys Vlasenko <dvlasenk at redhat.com>
> has been investigating the problems and adding test cases.  (Thanks, Denys!)
> (http://sourceware.org/systemtap/wiki/utrace/tests)
> 
> The current Fedora 9 and 10 kernels have the code that was current in my
> GIT tree and people.redhat.com patches before today.  That code exhibits
> several of these bugs.
> 
> I've fixed a bunch of problems but am still fighting with some loose ends.
> Since I've been at it for quite a while, I've decided to commit the newer
> code today even though some problems remain.  The current GIT branch and
> matching patches at http://people.redhat.com/roland/utrace/2.6-current/
> have my latest code now (vs v2.6.28-rc6ish).  I'm hoping some more eyeballs
> on the code might help me tie down some of the issues I'm still having.
> (I'm not updating the Fedora kernels with a new utrace patch yet.)
> 
> There are two things I'm currently struggling with.
> 
> 1. Intermittent failure of attach-into-signal.
>    The failure mode has changed from the original one,
>    and I haven't figured out what it's doing yet.
> 
> 2. Among the "make xcheck" tests, late-ptrace-may-attach-check
>    causes the the WARN_ON in ptrace_resumed() (kernel/ptrace.c:522)
>    to hit.  This might be ok to ignore, but I cannot figure out how
>    it happens and I don't like being confused!  If it can happen,
>    then I'm worried that there may be a problem with the assumptions
>    made about implicitly storing the old siginfo_t when ptrace stops.
>    I think the WARN_ON should not be happening so I want to grok how it does.
> 
> I was going to say, "All 'make check' tests pass except ..." before
> mentioning those two.  But now it appears I've just introduced regressions
> into block-step and step-jump-cont* too.  So those might need figured out.
> 
> If anyone has any insight into any of these problems, or questions about
> what I've recently done in the code, please pipe up!
> 
> 
> Thanks,
> Roland
> 
> 


-- 
Elena Zannoni, Oracle
Senior Engineering Manager, Tools/Languages - Linux Engineering
Blog: http://blogs.oracle.com/ezannoni
Email: elena.zannoni at oracle.com