This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some new Ptrace tests


Hi Andrew,

On Tue, 2006-06-27 at 15:24 -0400, Andrew Cagney wrote:
> > 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.

OK, I added a big and little endian pass of setting, reading and writing
the variables and committed that as attached.
I didn't find any new bugs in PtraceByteBuffer, but I did find one spot
in my original testcase where I did a getByte() which should have been a
getInt().

This does make one part of what I intended with the test-case not work.
I would have liked the test-case to show that you can easily get and set
values of variables in a PtraceByteBuffer text area. That was why in the
original version the forked process sets the values itself.

But since PtraceByteBuffer always defaults to big-endian there doesn't
seem to be a real way to do this. This would be possible if the
PtraceByteBuffer for the text area would be in the endianess of the
traced task. Does that make sense? Or is there a way to determine the
endianess of the traced task some other way?

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]