On Sat, 20 Dec 2014 22:03:34 +0000 Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 18 December 2014 at 16:34, Cornelia Huck <cornelia.h...@de.ibm.com> wrote: > > Next try for s390x updates. The previous build failures should be > > fixed now. > > Still not building on w32, I'm afraid. I think most of this is run-on > error from using __uint16_t &c rather than uint16_t &c. Sigh. Every time I try to set up a mingw build environment, I get lost in some library dependencies and give up. But yes, the __uint* stuff looks like some copy&paste error from the respective Linux headers. I'll leave it to Frank to fix that up. > > You also have a bunch of 64 bit constants like the ZPCI_*_ADDR > which need a trailing "ULL", and also some with a "UL" which > should probably be "ULL". For instance in > > #define ZPCI_STE_FLAG_MASK 0x7ffUL > #define ZPCI_STE_ADDR_MASK (~ZPCI_STE_FLAG_MASK) > > though ZPCI_STE_FLAG_MASK is OK by itself, when you use it > in ZPCI_STE_ADDR_MASK you will get the logical-negate done > at 32 bits before zero-extend to 64 bits, rather than a 64 > bit negate. > > (I think that "UL" is almost never correct in QEMU -- you > either want "at least 32 bits", in which case "U" is > sufficient, or you need "64 bits", in which case you need > "ULL".) That's probably also an artifact of grabbing the constants from Linux (where the code is 64 bit only). > > Some of those suffixes are provoking compiler warnings or > errors below, but some of them will just be silent wrong > behaviour, so you should probably eyeball the #defines... There are also some possibly dodgy places in non-pci code; I'll take a look at those as well.