[libvirt] kFreeBSD pdwtags make check failure

Guido Günther agx at sigxcpu.org
Fri May 31 19:42:04 UTC 2013


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
> 





More information about the libvir-list mailing list