[PVFS2-developers] return of 64 bit and request encode/decode

Pete Wyckoff pw at osc.edu
Tue Jun 14 19:11:05 EDT 2005


robl at mcs.anl.gov wrote on Tue, 14 Jun 2005 16:15 -0500:
> So we print out the usual suspects:
> 
> (gdb) p  req->cur[req->lvl].rq
> $3 = (PINT_Request *) 0x1011d090
> (gdb) p * req->cur[req->lvl].rq
> $4 = {offset = 0, num_ereqs = 1, num_blocks = 0, stride = 1, ub = 1, lb = 0, 
>   aggregate_size = 1, num_contig_chunks = 1, depth = 1, num_nested_req = 0, 
>   committed = -1, refcount = -1, ereq = 0xffffffa81011d090, 
>   sreq = 0xffffffa81011d090}
> 
> It looks like ereq and sreq are getting ... i dunno... sign extended?
> We already, thanks to Pete's suggestion, zero ereq and sreq before
> calling decode_uint32_t.  On a whim I tried zeroing it out with '0L'
> instead of plain 0 but with no effect.  

Not quite sign extended this time, but sure looks familiar.  The top
half is -6; I've no good explanation for why.

Here's the rundown again.

    PVFS_request is an in-memory structure containing poniters to
    other pointers.

    PINT_Request_encode linearizes those pointers into integral offsets.

    encode_PVFS_servreq_io calls PINT_Request_encode to do this
    conversion, then calls encode_PVFS_Request to put the encoded bits
    on the wire.

    The sreq and ereq fields are represented in-memory as pointers, thus
    the natural word size of the machine, so 32 or 64 bits accordingly.
    On the wire they are 32 bit uints, not related to any native size
    otherwise we couldn't talk to each other.

    The problems seem to be come from a maze of casts, first in this
    linearizing conversion, then on putting these ints on the wire, and
    back.

    Might PPC be a big-endian machine?  x86* are little-endian.

Can you try something like this in src/io/description/pint-request.h:

    send side:

    instead of
	encode_uint32_t(pptr, (u_int32_t*) &(rp+i)->ereq); \
    try
	{ u_int32_t encti = (u_int32_t)(uintptr_t) (rp+i)->ereq; \
	  encode_uint32_t(pptr, &encti); \
        }
    or similar until the compiler does not complain.

    receive side:

    instead of
	(rp+i)->ereq = 0; \
	decode_uint32_t(pptr, (u_int32_t*) &(rp+i)->ereq); \
    try
	{ u_int32_t encti; \
	  decode_uint32_t(pptr, &encti); \
	  (rp+i)->ereq = (PINT_Request *)(uintptr_t) encti; \
	}
    or so.  And ditto for sreq.

I'm guessing the cast to u_int32_t* is picking up the wrong half
of the dword on big-endian machines.  Another proof that god intended
the world to be little-endian if so.  :)

If not I'll write a little test program to figure this out better.

		-- Pete



More information about the PVFS2-developers mailing list