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
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list