1:16 p.m.
Hi,
make check on kFreeBSD currently fails with:
make[3]: Entering directory
`/data/home/jenkins/jobs/libvirt-build-debian-jessie-kfreebsd64/workspace/libvirt/src'
GEN remote_protocol-struct
--- remote_protocol-structs 2013-05-03 17:48:29.000000000 +0200
+++ remote_protocol-struct-t3 2013-05-30 22:25:36.716696829 +0200
@@ -67,7 +67,7 @@
struct remote_vcpu_info {
u_int number;
int state;
- uint64_t cpu_time;
+ long unsigned int cpu_time;
int cpu;
};
...
and way more. Full log at:
http://honk.sigxcpu.org:8001/job/libvirt-check-debian-jessie-kfreebsd64/2...
I do wonder what would be the right aproach to fix this up though. The
used types seem compatible at least.
Cheers,
-- Guido
1:31 p.m.
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?
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.
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
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?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:42 p.m.
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
4193
days inactive
4193
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
Guido Günther