Re: [Qemu-devel] [PULL v2 0/7] s390x patches for 2.3

[Frank Blaschka]

On Wed, Jan 07, 2015 at 04:08:13PM +0100, Cornelia Huck wrote:
> On Sat, 20 Dec 2014 22:03:34 +0000
> Peter Maydell <address@hidden> wrote:
> 
> > On 18 December 2014 at 16:34, Cornelia Huck <address@hidden> 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.
>

ok, I'm working on a patch to fix this but I hate to go on this way and steel
your time by let you compile test the changes. I do not have a windows
build system available so I'm wondering if there is some kind of public
infrastructure I can use to do a win build?

Thx for any pointers and help ...

> > 
> > 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.
> 
>