qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/9] exec: add endian specific phys ld/st functi


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/9] exec: add endian specific phys ld/st functions
Date: Wed, 06 Jul 2011 15:30:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Mnenhy/0.8.3 Thunderbird/3.1.10

On 07/06/2011 03:03 PM, Hannes Reinecke wrote:

uint32_t ldub_phys(target_phys_addr_t addr);
uint32_t lduw_phys(target_phys_addr_t addr);

Hmm? ldub is supposed to read an 'unsigned byte' (uint8_t),
and lduw is supposed to read an 'unsigned word' (uint16_t).

Why does it return an uint32_t?

I don't know if this is the reason, but uint{8,16}_t are promoted to a signed int. So when you do

  (uint64_t) (ldub_phys (addr) << 24)

you'd get a sign extension in bits 32-63. Admittedly a bit contrived, but it can happen and QEMU is full of such bugs:

    case 4:
        lba = (uint64_t) buf[9] | ((uint64_t) buf[8] << 8) |
              ((uint64_t) buf[7] << 16) | ((uint64_t) buf[6] << 24) |
              ((uint64_t) buf[5] << 32) | ((uint64_t) buf[4] << 40) |
              ((uint64_t) buf[3] << 48) | ((uint64_t) buf[2] << 56);
        break;

(found by Coverity).

This was the reason for my series at http://permalink.gmane.org/gmane.comp.emulators.qemu/105336 (which you reminded me to ping---thanks!)

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]