Re: utrace in rawhide

[Roland McGrath <roland at redhat dot com>]

> But what is rawhide?  Seen from  
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/,  
> the kernel is 2.6.17-1.2366.  Where can I get 2373?

Sorry, "in rawhide" doesn't necessarily mean "successfully built in rawhide".
;-)  There is a lot of flux in rawhide this week generally, and issues in
the kernel build aside from the utrace integration.  There may be some
delay in getting the published rpms updated when things are changing and
breaking fast; I think it's updated once a day and can that fail to happen
if there are bugs in building the distribution, which is not too uncommon
for rawhide.  Usually there will be something new and usable within a few
days at most.  Rawhide will become FC6 test2 next week, so things will be
fixed by then.  You can always see the complete Fedora Core development
sources going into the rpms with at most a few hours lag via cvs from
cvs.fedora.redhat.com (web pages there describe using cvs or cvsweb).  What
you find there might not be successfully built into rpms yet, or might be
built at Red Hat but not percolated to the download web site yet.

> To Roland, can you please give any pointer for me to try utrace on  
> ppc64....  build, setup, test and whatever you can thought of as  
> helpful.  Thanks!

Whenever you get a new rawhide kernel that works, that will be all you need
to be using utrace.  Right now, the most constructive way to help is with
testing of existing things that use ptrace on the new kernel.  The ptrace
system call implementation is now layered on top of the new utrace core.
So testing uses of ptrace tests the whole body of new code.  So, running
whatever there is using ptrace: use strace, use gdb, run the frysk test
suite, run the gdb test suite.  For all such tests you can do, run the test
on an old kernel that works (rawhide from a while back if it was stable for
you, or something more reliable like FC5), and compare those results as a
baseline with running that test on the new utrace-based kernel.  I'm not
interested in the absolute results--the exercise is not to debug strace, or
gdb, or frysk.  These tests exercise the kernel support for the ptrace
system call interface, and the new kernel aims to exactly match the defined
behavior of the old ptrace code.  What we need to examine is every
difference in behavior of a test between the old kernel and the new kernel.

Rick Moseley did some testing of the frysk suite on my kernels a while back
and found some problems, regressions from the stable kernel.  I still have
not gotten to debugging those, so if you use the frysk suite I won't be
surprised to see some regressions.  I'd appreciate the assistance of any
efforts you can make in whittling down each failure to the concise
description of what pattern of ptrace system calls elicited what kind of
wrong kernel behavior.  (The ideal for me is that it's reduced to a
self-contained all-C test case reproducing the bug using direct ptrace
calls, that I can use as a small regression test for kernel debugging and
to put into a kernel regression test suite.)

The gdb test suite is the most thorough and moderately torturous test of
ptrace (and by extension, all my new utrace infrastructure code) I know of.
I've just written up detailed instructions for the folks doing new utrace
arch support, on setting up and running it, comparing the results, and
doing all the myriad biarch variations that can be tested.  If you get to
the stage of wanting to run the hard tests and scour painfully for the
obscure problems, I can send you the same details.

For ppc64, I did already do the testing with gdb, including all the biarch
variations, though it was a while ago now the last time I did it.  It
should be done again, but there is good reason to hope that it will at
worst show minor regressions from what I had working before.

What I've not tested at all is the native ppc32 kernel.  I don't have an
old mac laptop lying around, nor a working qemu setup handy to try it.  
I did what I think is all the work for the arch support for ppc32 kernels
along with the ppc64 support and ppc32 users on ppc64 (which I tested).
(My only powerpc hardware is a Mac G5 supplied by IBM.)

In the near future, there will be another test suite specifically for newer
utrace stuff.  It will be useful to use that often on all kinds of machines
and look into anything that crops up.  But for now, by far the most
effective means of testing is normal stuff using good old crufty ptrace.


Thanks,
Roland