Hi Eric, On Fri, May 31, 2013 at 12:31:48PM -0600, Eric Blake wrote:
On 05/31/2013 12:16 PM, Guido Günther wrote:
Hi, make check on kFreeBSD currently fails with:
- uint64_t cpu_time; + long unsigned int cpu_time;
What version of pdwtags? Also, what version of rpcgen?
$ rpcgen --version rpcgen (Debian EGLIBC 2.17-3) 2.17 $ pdwtags --version v1.9
We are definitely requesting a 64-bit type in src/remote/remote_protocol.x, by our use of 'hyper':
struct remote_vcpu_info { unsigned int number; int state; unsigned hyper cpu_time; int cpu; };
Looking at the generated src/remote/remote_protocol.h, what do you see for remote_vcpu_info? On Linux/glibc, I see
struct remote_vcpu_info { u_int number; int state; uint64_t cpu_time; int cpu; };
so after translation through rpcgen and src/rpc/genprotocol.pl, it has turned 'hyper' into 'uint64_t' for me. I suspect that something different happened for you.
Same here, it has uint64_t.
I don't know if it is a difference in your version of rpcgen (as long as your platform is 64-bit, it actually seems okay; but it would be a disaster on a 32-bit platform), and knowing whether the generated .h
It's 64bit - otherwise I'd paniced.
files differ is important to decide whether the problem is in the rpcgen side or in the pdwtags side. Is this a case where rpc/genprotocol.pl merely needs to be taught a substitution rule that if rpcgen turned 'hyper' into 'long unsigned int', then this is turned back into uint64_t?
The pdwtags output then has the "long unsigned int cpu_time;" so it seems to me that pdwtags is reporting an long unsigned int where it should report a uint64_t. However if I prozess this struct s { uint64_t uit; } a; I get it correctly back from pdwtags like: struct s { uint64_t uit; /* 0 8 */ /* size: 8, cachelines: 1, members: 1 */ /* last cacheline: 8 bytes */ }; /* size: 8 */ which leaves me puzzled. Cheers, -- Guido
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org