Re: Some new Ptrace tests

[Andrew Cagney <cagney at redhat dot com>]

> On Fri, 2006-06-23 at 16:48 +0200, Mark Wielaard wrote:
>   
> > > On Fri, 2006-06-23 at 10:06 -0400, Andrew Cagney wrote:
> >     
> > > > > you may want to take a step back and look at 
> > > > > frysk.sys.PtraceByteBuffer.  The core and the ui access a thread's 
> > > > > memory via 64-bit[ish] byte buffers and not ptrace.
> > >       
> > > 
> > > Thanks! That is precisely what I need.
> >     
>
> And as a penance for not having seen that handy class earlier I wrote
> some tests for it. Also to figure out how to actually use this for
> variable and function content watching/manipulation. And those tests
> actually exposed a bug in PtraceByteBuffer.peek(). Patch for the test
> and the fix attached.
>
> 2006-06-26  Mark Wielaard  <mark@klomp.org>
>   
@redhat.com
>     * frysk-sys/frysk/sys/TestPtraceByteBuffer.java: New test.
>     * frysk-sys/frysk/sys/TestLib.java (intVal, byteVal, longVal):
>     New static fields.
>     (getIntValAddr, getByteValAddr, getLongValAddr): New native methods.
>     (getFuncAddr): Likewise.
>     (getFuncBytes): Likewise.
>     * frysk-sys/frysk/sys/cni/TestLib.cxx
>     (forkIt): Set intVal, byteVal and longVal for child process to
>     different values.
>     (dummyfunc): New static function.
>     (getIntValAddr, getByteValAddr, getLongValAddr): New method.
>     (getFuncAddr): Likewise.
>     (getFuncBytes): Likewise.
>
>     * frysk-sys/frysk/sys/cni/PtraceByteBuffer.cxx (peek): Use off when
>     storing bytes.
>
> In need to set the PtraceByteBuffer.Area.TEXT to ByteOrder.LITTLE_ENDIAN
> for reading and writing the variables. But I assume the text area has
> the native endianness of the target platform. Should the test figure out
> what the target endianness is. Or should PtraceByteBuffer itself return
> the areas in the target endianness? And is there a helper method already
> to get the endianness of the platform?
>
>   
PtraceByteBuffer, by default, is big-endian (same as nio's ByteBuffer).  
Instead of having the test know the host's byte order, can the tests be 
extended to be more byte-order independant.  For instance, instead of:

+    intVal = 52;

have

  unsigned char intValBE[4] = { 0, 0, 0, 52 }; // big endian
  unsigned char intValLE[4] = { 52, 0, 0, 0 }; // little endian

and then have the test work against both of those, for instance checking big-endian reads against the LE value.  This will of course still drive the ptrace byte buffer code, and more exaustively.

BTW, the inua tests are doing exactly this - they have raw bytes in memory and then read them using all possible combinations (see frysk-imports && make check)

If you do that, check it in :-)

Andrew