On 03/13/2017 03:07 PM, Dr. David Alan Gilbert wrote: > * Eric Blake (ebl...@redhat.com) wrote: >> An upcoming patch will let the compiler warn us when we are silently >> losing precision in traces; update the trace definitions to pass >> through the full value at the callsite. >> >> Signed-off-by: Eric Blake <ebl...@redhat.com> >> --- >> migration/trace-events | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >>
>> -postcopy_ram_fault_thread_request(uint64_t hostaddr, const char *ramblock,
>> size_t offset) "Request for HVA=%" PRIx64 " rb=%s offset=%zx"
>> +postcopy_ram_fault_thread_request(unsigned long long hostaddr, const char
>> *ramblock, size_t offset) "Request for HVA=%llx rb=%s offset=%zx"
>
> Hmm - why?
> That's called as:
> trace_postcopy_ram_fault_thread_request(msg.arg.pagefault.address,
> qemu_ram_get_idstr(rb),
> rb_offset);
> struct uffd_msg msg;
> struct uffd_msg {
> ..
> union {
> struct {
> __u64 flags;
> __u64 address;
> } pagefault;
> ..
> } arg;
> }
>
> So why is a PRIx64 not the right way to print a __u64 ?
Because __u64 is not the same type as uint64_t. On 64-bit Linux, __u64
is 'unsigned long long', while uint64_t is 'unsigned long'.
> (I prefer %llx to the horrid PRIx64 syntax, but it still seems weird in this
> case)
As it is, I'm not sure if __u64 is always 'unsigned long long' in ALL
Linux clients; an even-more-conservative patch would be to switch all
callers to use explicit casts to something (like uint64_t or unsigned
long long) that we have full control over, rather than passing __u64
where we have no control over what type it ultimately resolves to.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
