s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Philippe Mathieu-Daudé]

Hi Thomas, Daniel, Stefano,

Regarding the following warning (GCC 11 on Fedora 34):

In file included from pc-bios/s390-ccw/main.c:11:

In function ‘memset’,

    inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,

    inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:

pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]

   28 |         p[i] = c;

      |         ~~~~~^~~

Daniel were right on IRC:

danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
is just a constant address 0x10008
danpb: the compiler doesn't now how big that is, so it seems to assume
it is zero length

This is a known GCC issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
"gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
pointer from integer literal"

Regards,

Phil.

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Thomas Huth]

On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
> Hi Thomas, Daniel, Stefano,
> 
> Regarding the following warning (GCC 11 on Fedora 34):
> 
> In file included from pc-bios/s390-ccw/main.c:11:
> 
> In function ‘memset’,
> 
>      inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
> 
>      inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
> 
> pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
> size 0 [-Wstringop-overflow=]
> 
>     28 |         p[i] = c;
> 
>        |         ~~~~~^~~
> 
> Daniel were right on IRC:
> 
> danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
> is just a constant address 0x10008
> danpb: the compiler doesn't now how big that is, so it seems to assume
> it is zero length
> 
> This is a known GCC issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
> pointer from integer literal"

  Hi Philippe,

thanks for following up with the gcc bugzilla!

... so the problem is that GCC thinks we're in fact dereferencing a NULL 
pointer at offset 0x10008 here? Wow, that's ... crazy.

Not sure what to do now - wait for the bug to get resolved? Compile the 
s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there 
to hope that these silence the compiler warnings? ... I tend to wait for the 
bug ticket to see whether the GCC folks change the behavior of the compiler 
again, but I'm open for other suggestions.

  Thomas

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Christian Borntraeger]

On 22.04.21 06:47, Thomas Huth wrote:
> On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
>> Hi Thomas, Daniel, Stefano,
>>
>> Regarding the following warning (GCC 11 on Fedora 34):
>>
>> In file included from pc-bios/s390-ccw/main.c:11:
>>
>> In function ‘memset’,
>>
>>      inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
>>
>>      inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
>>
>> pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
>> size 0 [-Wstringop-overflow=]
>>
>>     28 |         p[i] = c;
>>
>>        |         ~~~~~^~~
>>
>> Daniel were right on IRC:
>>
>> danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
>> is just a constant address 0x10008
>> danpb: the compiler doesn't now how big that is, so it seems to assume
>> it is zero length
>>
>> This is a known GCC issue:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
>> pointer from integer literal"
> 
> Hi Philippe,
> 
> thanks for following up with the gcc bugzilla!
> 
> ... so the problem is that GCC thinks we're in fact dereferencing a NULL pointer at offset 0x10008 here? Wow, that's ... crazy.
> 
> Not sure what to do now - wait for the bug to get resolved? Compile the s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there to hope that these silence the compiler warnings? ... I tend to wait for the bug ticket to see whether the GCC folks change the behavior of the compiler again, but I'm open for other suggestions.

I tend to follow the Linux kernel. If the compiler tends to produce stupid errors,
silence them with Wno-*.
I think it makes no sense to have warnings with a high tendency of false positives in a
project with Werror.

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Daniel P. Berrangé]

On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote:
> On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
> > Hi Thomas, Daniel, Stefano,
> > 
> > Regarding the following warning (GCC 11 on Fedora 34):
> > 
> > In file included from pc-bios/s390-ccw/main.c:11:
> > 
> > In function ‘memset’,
> > 
> >      inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
> > 
> >      inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
> > 
> > pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
> > size 0 [-Wstringop-overflow=]
> > 
> >     28 |         p[i] = c;
> > 
> >        |         ~~~~~^~~
> > 
> > Daniel were right on IRC:
> > 
> > danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
> > is just a constant address 0x10008
> > danpb: the compiler doesn't now how big that is, so it seems to assume
> > it is zero length
> > 
> > This is a known GCC issue:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> > "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
> > pointer from integer literal"
> 
>  Hi Philippe,
> 
> thanks for following up with the gcc bugzilla!
> 
> ... so the problem is that GCC thinks we're in fact dereferencing a NULL
> pointer at offset 0x10008 here? Wow, that's ... crazy.
> 
> Not sure what to do now - wait for the bug to get resolved? Compile the
> s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there
> to hope that these silence the compiler warnings? ... I tend to wait for the
> bug ticket to see whether the GCC folks change the behavior of the compiler
> again, but I'm open for other suggestions.

Assuming it is just this one place in the code ,then we should just
use "pragma" to temporarily disable/re-enable that single warning flag
either side of the problem.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Peter Maydell]

On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote:
> > On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
> > > Hi Thomas, Daniel, Stefano,
> > >
> > > Regarding the following warning (GCC 11 on Fedora 34):
> > >
> > > In file included from pc-bios/s390-ccw/main.c:11:
> > >
> > > In function ‘memset’,
> > >
> > >      inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
> > >
> > >      inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
> > >
> > > pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
> > > size 0 [-Wstringop-overflow=]
> > >
> > >     28 |         p[i] = c;
> > >
> > >        |         ~~~~~^~~
> > >
> > > Daniel were right on IRC:
> > >
> > > danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
> > > is just a constant address 0x10008
> > > danpb: the compiler doesn't now how big that is, so it seems to assume
> > > it is zero length
> > >
> > > This is a known GCC issue:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> > > "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
> > > pointer from integer literal"
> >
> >  Hi Philippe,
> >
> > thanks for following up with the gcc bugzilla!
> >
> > ... so the problem is that GCC thinks we're in fact dereferencing a NULL
> > pointer at offset 0x10008 here? Wow, that's ... crazy.
> >
> > Not sure what to do now - wait for the bug to get resolved? Compile the
> > s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there
> > to hope that these silence the compiler warnings? ... I tend to wait for the
> > bug ticket to see whether the GCC folks change the behavior of the compiler
> > again, but I'm open for other suggestions.
>
> Assuming it is just this one place in the code ,then we should just
> use "pragma" to temporarily disable/re-enable that single warning flag
> either side of the problem.

The gcc bug report suggests that use of 'volatile' also sidesteps
the warning. Is that a sensible approach here ?

thanks
-- PMM

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Philippe Mathieu-Daudé]

On 4/22/21 12:30 PM, Peter Maydell wrote:
> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote:
>>> On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
>>>> Hi Thomas, Daniel, Stefano,
>>>>
>>>> Regarding the following warning (GCC 11 on Fedora 34):
>>>>
>>>> In file included from pc-bios/s390-ccw/main.c:11:
>>>>
>>>> In function ‘memset’,
>>>>
>>>>      inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
>>>>
>>>>      inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
>>>>
>>>> pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
>>>> size 0 [-Wstringop-overflow=]
>>>>
>>>>     28 |         p[i] = c;
>>>>
>>>>        |         ~~~~~^~~
>>>>
>>>> Daniel were right on IRC:
>>>>
>>>> danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
>>>> is just a constant address 0x10008
>>>> danpb: the compiler doesn't now how big that is, so it seems to assume
>>>> it is zero length
>>>>
>>>> This is a known GCC issue:
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>>>> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
>>>> pointer from integer literal"
>>>
>>>  Hi Philippe,
>>>
>>> thanks for following up with the gcc bugzilla!
>>>
>>> ... so the problem is that GCC thinks we're in fact dereferencing a NULL
>>> pointer at offset 0x10008 here? Wow, that's ... crazy.
>>>
>>> Not sure what to do now - wait for the bug to get resolved? Compile the
>>> s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there
>>> to hope that these silence the compiler warnings? ... I tend to wait for the
>>> bug ticket to see whether the GCC folks change the behavior of the compiler
>>> again, but I'm open for other suggestions.
>>
>> Assuming it is just this one place in the code ,then we should just
>> use "pragma" to temporarily disable/re-enable that single warning flag
>> either side of the problem.
> 
> The gcc bug report suggests that use of 'volatile' also sidesteps
> the warning. Is that a sensible approach here ?

I'm not sure I got it right... I tried:

-    memset((char *)S390EP, 0, 6);
+    memset((char *)(volatile char *)S390EP, 0, 6);

But no change (still -Wstringop-overflow=).

If I use:

-    memset((char *)S390EP, 0, 6);
+    memset((volatile char *)S390EP, 0, 6);

I still have -Wstringop-overflow=, but also:

pc-bios/s390-ccw/main.c:185:12: warning: passing argument 1 of ‘memset’
discards ‘volatile’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
pc-bios/s390-ccw/libc.h:22:34: note: expected ‘void *’ but argument is
of type ‘volatile char *’

This silents the warning however:

-- >8 --
diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
index bcdc45732d..2dea399904 100644
--- a/pc-bios/s390-ccw/libc.h
+++ b/pc-bios/s390-ccw/libc.h
@@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
 typedef unsigned int       uint32_t;
 typedef unsigned long long uint64_t;

+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
 static inline void *memset(void *s, int c, size_t n)
 {
     size_t i;
@@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)

     return s;
 }
+#pragma GCC diagnostic pop

 static inline void *memcpy(void *s1, const void *s2, size_t n)
 {
---

Oddly this code doesn't emit any warning:

  if (!memcmp((char *)S390EP, "S390EP", 6)) {
  ...

Regards,

Phil.

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Thomas Huth]

On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
> On 4/22/21 12:30 PM, Peter Maydell wrote:
>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>
>>> On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote:
>>>> On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
>>>>> Hi Thomas, Daniel, Stefano,
>>>>>
>>>>> Regarding the following warning (GCC 11 on Fedora 34):
>>>>>
>>>>> In file included from pc-bios/s390-ccw/main.c:11:
>>>>>
>>>>> In function ‘memset’,
>>>>>
>>>>>       inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
>>>>>
>>>>>       inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
>>>>>
>>>>> pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
>>>>> size 0 [-Wstringop-overflow=]
>>>>>
>>>>>      28 |         p[i] = c;
>>>>>
>>>>>         |         ~~~~~^~~
>>>>>
>>>>> Daniel were right on IRC:
>>>>>
>>>>> danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
>>>>> is just a constant address 0x10008
>>>>> danpb: the compiler doesn't now how big that is, so it seems to assume
>>>>> it is zero length
>>>>>
>>>>> This is a known GCC issue:
>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>>>>> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
>>>>> pointer from integer literal"
>>>>
>>>>   Hi Philippe,
>>>>
>>>> thanks for following up with the gcc bugzilla!
>>>>
>>>> ... so the problem is that GCC thinks we're in fact dereferencing a NULL
>>>> pointer at offset 0x10008 here? Wow, that's ... crazy.
>>>>
>>>> Not sure what to do now - wait for the bug to get resolved? Compile the
>>>> s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there
>>>> to hope that these silence the compiler warnings? ... I tend to wait for the
>>>> bug ticket to see whether the GCC folks change the behavior of the compiler
>>>> again, but I'm open for other suggestions.
>>>
>>> Assuming it is just this one place in the code ,then we should just
>>> use "pragma" to temporarily disable/re-enable that single warning flag
>>> either side of the problem.
>>
>> The gcc bug report suggests that use of 'volatile' also sidesteps
>> the warning. Is that a sensible approach here ?
> 
> I'm not sure I got it right... I tried:
> 
> -    memset((char *)S390EP, 0, 6);
> +    memset((char *)(volatile char *)S390EP, 0, 6);
> 
> But no change (still -Wstringop-overflow=).
> 
> If I use:
> 
> -    memset((char *)S390EP, 0, 6);
> +    memset((volatile char *)S390EP, 0, 6);
> 
> I still have -Wstringop-overflow=, but also:
> 
> pc-bios/s390-ccw/main.c:185:12: warning: passing argument 1 of ‘memset’
> discards ‘volatile’ qualifier from pointer target type
> [-Wdiscarded-qualifiers]
> pc-bios/s390-ccw/libc.h:22:34: note: expected ‘void *’ but argument is
> of type ‘volatile char *’

Yeah, the warning happens in the memset(), so it likely doesn't help to 
change the parameter here.

> This silents the warning however:
> 
> -- >8 --
> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
> index bcdc45732d..2dea399904 100644
> --- a/pc-bios/s390-ccw/libc.h
> +++ b/pc-bios/s390-ccw/libc.h
> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>   typedef unsigned int       uint32_t;
>   typedef unsigned long long uint64_t;
> 
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>   static inline void *memset(void *s, int c, size_t n)
>   {
>       size_t i;
> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
> 
>       return s;
>   }
> +#pragma GCC diagnostic pop

Honestly, that compiler "bug" sounds like it could trigger at any other spot 
in the bios code, too, since we are doing lots of direct accesses to low 
memory there. I think it's likely best if we shut it off with 
-Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ... could you please 
try to add it there?

  Thomas

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Christian Borntraeger]

On 22.04.21 13:47, Thomas Huth wrote:
> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>>
>>>> On Thu, Apr 22, 2021 at 06:47:30AM +0200, Thomas Huth wrote:
>>>>> On 22/04/2021 06.18, Philippe Mathieu-Daudé wrote:
>>>>>> Hi Thomas, Daniel, Stefano,
>>>>>>
>>>>>> Regarding the following warning (GCC 11 on Fedora 34):
>>>>>>
>>>>>> In file included from pc-bios/s390-ccw/main.c:11:
>>>>>>
>>>>>> In function ‘memset’,
>>>>>>
>>>>>>       inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
>>>>>>
>>>>>>       inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
>>>>>>
>>>>>> pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of
>>>>>> size 0 [-Wstringop-overflow=]
>>>>>>
>>>>>>      28 |         p[i] = c;
>>>>>>
>>>>>>         |         ~~~~~^~~
>>>>>>
>>>>>> Daniel were right on IRC:
>>>>>>
>>>>>> danpb: it is from a call  memset((char *)S390EP, 0, 6)     where  S390EP
>>>>>> is just a constant address 0x10008
>>>>>> danpb: the compiler doesn't now how big that is, so it seems to assume
>>>>>> it is zero length
>>>>>>
>>>>>> This is a known GCC issue:
>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>>>>>> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
>>>>>> pointer from integer literal"
>>>>>
>>>>>   Hi Philippe,
>>>>>
>>>>> thanks for following up with the gcc bugzilla!
>>>>>
>>>>> ... so the problem is that GCC thinks we're in fact dereferencing a NULL
>>>>> pointer at offset 0x10008 here? Wow, that's ... crazy.
>>>>>
>>>>> Not sure what to do now - wait for the bug to get resolved? Compile the
>>>>> s390-ccw bios with -Wno-stringop-overread ? Add "volatiles" here and there
>>>>> to hope that these silence the compiler warnings? ... I tend to wait for the
>>>>> bug ticket to see whether the GCC folks change the behavior of the compiler
>>>>> again, but I'm open for other suggestions.
>>>>
>>>> Assuming it is just this one place in the code ,then we should just
>>>> use "pragma" to temporarily disable/re-enable that single warning flag
>>>> either side of the problem.
>>>
>>> The gcc bug report suggests that use of 'volatile' also sidesteps
>>> the warning. Is that a sensible approach here ?
>>
>> I'm not sure I got it right... I tried:
>>
>> -    memset((char *)S390EP, 0, 6);
>> +    memset((char *)(volatile char *)S390EP, 0, 6);
>>
>> But no change (still -Wstringop-overflow=).
>>
>> If I use:
>>
>> -    memset((char *)S390EP, 0, 6);
>> +    memset((volatile char *)S390EP, 0, 6);
>>
>> I still have -Wstringop-overflow=, but also:
>>
>> pc-bios/s390-ccw/main.c:185:12: warning: passing argument 1 of ‘memset’
>> discards ‘volatile’ qualifier from pointer target type
>> [-Wdiscarded-qualifiers]
>> pc-bios/s390-ccw/libc.h:22:34: note: expected ‘void *’ but argument is
>> of type ‘volatile char *’
> 
> Yeah, the warning happens in the memset(), so it likely doesn't help to change the parameter here.
> 
>> This silents the warning however:
>>
>> -- >8 --
>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>> index bcdc45732d..2dea399904 100644
>> --- a/pc-bios/s390-ccw/libc.h
>> +++ b/pc-bios/s390-ccw/libc.h
>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>   typedef unsigned int       uint32_t;
>>   typedef unsigned long long uint64_t;
>>
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>   static inline void *memset(void *s, int c, size_t n)
>>   {
>>       size_t i;
>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
>>
>>       return s;
>>   }
>> +#pragma GCC diagnostic pop
> 
> Honestly, that compiler "bug" sounds like it could trigger at any other spot in the bios code, too, since we are doing lots of direct accesses to low memory there. I think it's likely best if we shut it off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ... could you please try to add it there?

Ack. This warning does more harm than good in here.

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Philippe Mathieu-Daudé]

On 4/22/21 2:41 PM, Christian Borntraeger wrote:
> On 22.04.21 13:47, Thomas Huth wrote:
>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>> <berrange@redhat.com> wrote:

>>> This silents the warning however:
>>>
>>> -- >8 --
>>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>> index bcdc45732d..2dea399904 100644
>>> --- a/pc-bios/s390-ccw/libc.h
>>> +++ b/pc-bios/s390-ccw/libc.h
>>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>   typedef unsigned int       uint32_t;
>>>   typedef unsigned long long uint64_t;
>>>
>>> +#pragma GCC diagnostic push
>>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>   static inline void *memset(void *s, int c, size_t n)
>>>   {
>>>       size_t i;
>>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
>>>
>>>       return s;
>>>   }
>>> +#pragma GCC diagnostic pop
>>
>> Honestly, that compiler "bug" sounds like it could trigger at any
>> other spot in the bios code, too, since we are doing lots of direct
>> accesses to low memory there. I think it's likely best if we shut it
>> off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>> could you please try to add it there?
> 

We are good with:

-- >8 --
diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
index 29fd9019b8..dcec09b6f9 100644
--- a/pc-bios/s390-ccw/Makefile
+++ b/pc-bios/s390-ccw/Makefile
@@ -8,6 +8,9 @@ CFLAGS = -O2 -g
 quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
$1, @$1))
 cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
/dev/null \
              2>&1 && echo OK), $1, $2)
+cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
+                >/dev/null 2>&1 && echo OK), $2, $3)

 VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
 set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
$(PATTERN) $1)))
@@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
menu.o \
          virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o dasd-ipl.o

 QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
+QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS), -Wno-stringop-overflow)
 QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
-fno-common -fPIE
 QEMU_CFLAGS += -fwrapv -fno-strict-aliasing -fno-asynchronous-unwind-tables
 QEMU_CFLAGS += $(call cc-option, $(QEMU_CFLAGS), -fno-stack-protector)
---

> Ack. This warning does more harm than good in here.
>

Patch coming.

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Thomas Huth]

On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
> On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>> On 22.04.21 13:47, Thomas Huth wrote:
>>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>> <berrange@redhat.com> wrote:
> 
>>>> This silents the warning however:
>>>>
>>>> -- >8 --
>>>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>>> index bcdc45732d..2dea399904 100644
>>>> --- a/pc-bios/s390-ccw/libc.h
>>>> +++ b/pc-bios/s390-ccw/libc.h
>>>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>>    typedef unsigned int       uint32_t;
>>>>    typedef unsigned long long uint64_t;
>>>>
>>>> +#pragma GCC diagnostic push
>>>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>>    static inline void *memset(void *s, int c, size_t n)
>>>>    {
>>>>        size_t i;
>>>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
>>>>
>>>>        return s;
>>>>    }
>>>> +#pragma GCC diagnostic pop
>>>
>>> Honestly, that compiler "bug" sounds like it could trigger at any
>>> other spot in the bios code, too, since we are doing lots of direct
>>> accesses to low memory there. I think it's likely best if we shut it
>>> off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>>> could you please try to add it there?
>>
> 
> We are good with:
> 
> -- >8 --
> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
> index 29fd9019b8..dcec09b6f9 100644
> --- a/pc-bios/s390-ccw/Makefile
> +++ b/pc-bios/s390-ccw/Makefile
> @@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>   quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
> $1, @$1))
>   cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
> /dev/null \
>                2>&1 && echo OK), $1, $2)
> +cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
> +                >/dev/null 2>&1 && echo OK), $2, $3)
> 
>   VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>   set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
> $(PATTERN) $1)))
> @@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
> menu.o \
>            virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o dasd-ipl.o
> 
>   QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
> +QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS), -Wno-stringop-overflow)
>   QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks

I think you don't need the "cc-c-option" magic here. Just add the 
-Wno-stringop-overflow. All supported versions of GCC and Clang simply 
silently ignore unknown -Wno-something options (try e.g. "gcc 
-Wno-yadayadayada" on the command line).

  Thomas

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Philippe Mathieu-Daudé]

On 4/22/21 5:38 PM, Thomas Huth wrote:
> On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
>> On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>>> On 22.04.21 13:47, Thomas Huth wrote:
>>>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>>> <berrange@redhat.com> wrote:

>> We are good with:
>>
>> -- >8 --
>> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
>> index 29fd9019b8..dcec09b6f9 100644
>> --- a/pc-bios/s390-ccw/Makefile
>> +++ b/pc-bios/s390-ccw/Makefile
>> @@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>>   quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
>> $1, @$1))
>>   cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
>> /dev/null \
>>                2>&1 && echo OK), $1, $2)
>> +cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>> +                >/dev/null 2>&1 && echo OK), $2, $3)
>>
>>   VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>>   set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
>> $(PATTERN) $1)))
>> @@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
>> menu.o \
>>            virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o dasd-ipl.o
>>
>>   QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
>> +QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS),
>> -Wno-stringop-overflow)
>>   QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
> 
> I think you don't need the "cc-c-option" magic here. Just add the
> -Wno-stringop-overflow. All supported versions of GCC and Clang simply
> silently ignore unknown -Wno-something options (try e.g. "gcc
> -Wno-yadayadayada" on the command line).

Indeed, TIL :)

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Stefano Garzarella]

On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
>On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
>>On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>>>On 22.04.21 13:47, Thomas Huth wrote:
>>>>On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>>>On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>>>On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>>><berrange@redhat.com> wrote:
>>
>>>>>This silents the warning however:
>>>>>
>>>>>-- >8 --
>>>>>diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>>>>index bcdc45732d..2dea399904 100644
>>>>>--- a/pc-bios/s390-ccw/libc.h
>>>>>+++ b/pc-bios/s390-ccw/libc.h
>>>>>@@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>>>   typedef unsigned int       uint32_t;
>>>>>   typedef unsigned long long uint64_t;
>>>>>
>>>>>+#pragma GCC diagnostic push
>>>>>+#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>>>   static inline void *memset(void *s, int c, size_t n)
>>>>>   {
>>>>>       size_t i;
>>>>>@@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
>>>>>
>>>>>       return s;
>>>>>   }
>>>>>+#pragma GCC diagnostic pop
>>>>
>>>>Honestly, that compiler "bug" sounds like it could trigger at any
>>>>other spot in the bios code, too, since we are doing lots of direct
>>>>accesses to low memory there. I think it's likely best if we shut it
>>>>off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>>>>could you please try to add it there?
>>>
>>
>>We are good with:
>>
>>-- >8 --
>>diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
>>index 29fd9019b8..dcec09b6f9 100644
>>--- a/pc-bios/s390-ccw/Makefile
>>+++ b/pc-bios/s390-ccw/Makefile
>>@@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>>  quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
>>$1, @$1))
>>  cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
>>/dev/null \
>>               2>&1 && echo OK), $1, $2)
>>+cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>>+                >/dev/null 2>&1 && echo OK), $2, $3)
>>
>>  VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>>  set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
>>$(PATTERN) $1)))
>>@@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
>>menu.o \
>>           virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o dasd-ipl.o
>>
>>  QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
>>+QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS), -Wno-stringop-overflow)
>>  QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
>
>I think you don't need the "cc-c-option" magic here. Just add the 
>-Wno-stringop-overflow. All supported versions of GCC and Clang simply 
>silently ignore unknown -Wno-something options (try e.g. "gcc 
>-Wno-yadayadayada" on the command line).

Clang seems not to like it. It's always a mess to do anything for gcc 
and clang :-(

Maybe we can set also `-Wno-unknown-warning-option`.

$ clang -Wno-stringop-overflow -Werror main.c
error: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Werror,-Wunknown-warning-option]

$ clang --version
clang version 11.0.0 (Fedora 11.0.0-2.fc33

Stefano

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Thomas Huth]

On 22/04/2021 17.52, Stefano Garzarella wrote:
> On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
>> On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
>>> On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>>>> On 22.04.21 13:47, Thomas Huth wrote:
>>>>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>>>> <berrange@redhat.com> wrote:
>>>
>>>>>> This silents the warning however:
>>>>>>
>>>>>> -- >8 --
>>>>>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>>>>> index bcdc45732d..2dea399904 100644
>>>>>> --- a/pc-bios/s390-ccw/libc.h
>>>>>> +++ b/pc-bios/s390-ccw/libc.h
>>>>>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>>>>   typedef unsigned int       uint32_t;
>>>>>>   typedef unsigned long long uint64_t;
>>>>>>
>>>>>> +#pragma GCC diagnostic push
>>>>>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>>>>   static inline void *memset(void *s, int c, size_t n)
>>>>>>   {
>>>>>>       size_t i;
>>>>>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
>>>>>>
>>>>>>       return s;
>>>>>>   }
>>>>>> +#pragma GCC diagnostic pop
>>>>>
>>>>> Honestly, that compiler "bug" sounds like it could trigger at any
>>>>> other spot in the bios code, too, since we are doing lots of direct
>>>>> accesses to low memory there. I think it's likely best if we shut it
>>>>> off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>>>>> could you please try to add it there?
>>>>
>>>
>>> We are good with:
>>>
>>> -- >8 --
>>> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
>>> index 29fd9019b8..dcec09b6f9 100644
>>> --- a/pc-bios/s390-ccw/Makefile
>>> +++ b/pc-bios/s390-ccw/Makefile
>>> @@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>>>  quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
>>> $1, @$1))
>>>  cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
>>> /dev/null \
>>>               2>&1 && echo OK), $1, $2)
>>> +cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>>> +                >/dev/null 2>&1 && echo OK), $2, $3)
>>>
>>>  VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>>>  set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
>>> $(PATTERN) $1)))
>>> @@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
>>> menu.o \
>>>           virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o dasd-ipl.o
>>>
>>>  QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
>>> +QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS), -Wno-stringop-overflow)
>>>  QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
>>
>> I think you don't need the "cc-c-option" magic here. Just add the 
>> -Wno-stringop-overflow. All supported versions of GCC and Clang simply 
>> silently ignore unknown -Wno-something options (try e.g. "gcc 
>> -Wno-yadayadayada" on the command line).
> 
> Clang seems not to like it. It's always a mess to do anything for gcc and 
> clang :-(
> 
> Maybe we can set also `-Wno-unknown-warning-option`.
> 
> $ clang -Wno-stringop-overflow -Werror main.c
> error: unknown warning option '-Wno-stringop-overflow'; did you mean 
> '-Wno-shift-overflow'? [-Werror,-Wunknown-warning-option]

D'oh, I was pretty sure that Clang behaves the same with regards to 
-Wno-something, but seems I was wrong, sorry.

So I think we should simply keep this v1 of Philippe's patch.

I'll queue it to my s390-ccw branch.

  Thomas

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Philippe Mathieu-Daudé]

On 4/22/21 6:07 PM, Thomas Huth wrote:
> On 22/04/2021 17.52, Stefano Garzarella wrote:
>> On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
>>> On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
>>>> On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>>>>> On 22.04.21 13:47, Thomas Huth wrote:
>>>>>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>>>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>>>>> <berrange@redhat.com> wrote:
>>>>
>>>>>>> This silents the warning however:
>>>>>>>
>>>>>>> -- >8 --
>>>>>>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>>>>>> index bcdc45732d..2dea399904 100644
>>>>>>> --- a/pc-bios/s390-ccw/libc.h
>>>>>>> +++ b/pc-bios/s390-ccw/libc.h
>>>>>>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>>>>>   typedef unsigned int       uint32_t;
>>>>>>>   typedef unsigned long long uint64_t;
>>>>>>>
>>>>>>> +#pragma GCC diagnostic push
>>>>>>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>>>>>   static inline void *memset(void *s, int c, size_t n)
>>>>>>>   {
>>>>>>>       size_t i;
>>>>>>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c,
>>>>>>> size_t n)
>>>>>>>
>>>>>>>       return s;
>>>>>>>   }
>>>>>>> +#pragma GCC diagnostic pop
>>>>>>
>>>>>> Honestly, that compiler "bug" sounds like it could trigger at any
>>>>>> other spot in the bios code, too, since we are doing lots of direct
>>>>>> accesses to low memory there. I think it's likely best if we shut it
>>>>>> off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>>>>>> could you please try to add it there?
>>>>>
>>>>
>>>> We are good with:
>>>>
>>>> -- >8 --
>>>> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
>>>> index 29fd9019b8..dcec09b6f9 100644
>>>> --- a/pc-bios/s390-ccw/Makefile
>>>> +++ b/pc-bios/s390-ccw/Makefile
>>>> @@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>>>>  quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
>>>> $1, @$1))
>>>>  cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
>>>> /dev/null \
>>>>               2>&1 && echo OK), $1, $2)
>>>> +cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>>>> +                >/dev/null 2>&1 && echo OK), $2, $3)
>>>>
>>>>  VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>>>>  set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
>>>> $(PATTERN) $1)))
>>>> @@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
>>>> menu.o \
>>>>           virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o
>>>> dasd-ipl.o
>>>>
>>>>  QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
>>>> +QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS),
>>>> -Wno-stringop-overflow)
>>>>  QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
>>>
>>> I think you don't need the "cc-c-option" magic here. Just add the
>>> -Wno-stringop-overflow. All supported versions of GCC and Clang
>>> simply silently ignore unknown -Wno-something options (try e.g. "gcc
>>> -Wno-yadayadayada" on the command line).
>>
>> Clang seems not to like it. It's always a mess to do anything for gcc
>> and clang :-(

I didn't know we could build s390-ccw with clang.

Not with clang-12:

clang version 12.0.0 (Fedora 12.0.0-0.3.rc1.fc34)

warning: unknown warning option '-Wold-style-declaration'; did you mean
'-Wout-of-line-declaration'? [-Wunknown-warning-option]
warning: unknown warning option '-Wimplicit-fallthrough=2'; did you mean
'-Wimplicit-fallthrough'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-overflow'; did you mean
'-Wno-shift-overflow'? [-Wunknown-warning-option]
warning: unknown warning option '-Wold-style-declaration'; did you mean
'-Wout-of-line-declaration'? [-Wunknown-warning-option]
warning: unknown warning option '-Wimplicit-fallthrough=2'; did you mean
'-Wimplicit-fallthrough'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-overflow'; did you mean
'-Wno-shift-overflow'? [-Wunknown-warning-option]
error: unknown target CPU 'z900'
note: valid target CPU values are: arch8, z10, arch9, z196, arch10,
zEC12, arch11, z13, arch12, z14, arch13, z15

>> Maybe we can set also `-Wno-unknown-warning-option`.
>>
>> $ clang -Wno-stringop-overflow -Werror main.c
>> error: unknown warning option '-Wno-stringop-overflow'; did you mean
>> '-Wno-shift-overflow'? [-Werror,-Wunknown-warning-option]
> 
> D'oh, I was pretty sure that Clang behaves the same with regards to
> -Wno-something, but seems I was wrong, sorry.
> 
> So I think we should simply keep this v1 of Philippe's patch.
> 
> I'll queue it to my s390-ccw branch.

Thanks!

Phil.

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Stefano Garzarella]

On Thu, Apr 22, 2021 at 06:54:21PM +0200, Philippe Mathieu-Daudé wrote:
>On 4/22/21 6:07 PM, Thomas Huth wrote:
>> On 22/04/2021 17.52, Stefano Garzarella wrote:
>>> On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
>>>> On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
>>>>> On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>>>>>> On 22.04.21 13:47, Thomas Huth wrote:
>>>>>>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>>>>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>>>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>>>>>> <berrange@redhat.com> wrote:
>>>>>
>>>>>>>> This silents the warning however:
>>>>>>>>
>>>>>>>> -- >8 --
>>>>>>>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>>>>>>> index bcdc45732d..2dea399904 100644
>>>>>>>> --- a/pc-bios/s390-ccw/libc.h
>>>>>>>> +++ b/pc-bios/s390-ccw/libc.h
>>>>>>>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>>>>>>   typedef unsigned int       uint32_t;
>>>>>>>>   typedef unsigned long long uint64_t;
>>>>>>>>
>>>>>>>> +#pragma GCC diagnostic push
>>>>>>>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>>>>>>   static inline void *memset(void *s, int c, size_t n)
>>>>>>>>   {
>>>>>>>>       size_t i;
>>>>>>>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c,
>>>>>>>> size_t n)
>>>>>>>>
>>>>>>>>       return s;
>>>>>>>>   }
>>>>>>>> +#pragma GCC diagnostic pop
>>>>>>>
>>>>>>> Honestly, that compiler "bug" sounds like it could trigger at any
>>>>>>> other spot in the bios code, too, since we are doing lots of direct
>>>>>>> accesses to low memory there. I think it's likely best if we shut it
>>>>>>> off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>>>>>>> could you please try to add it there?
>>>>>>
>>>>>
>>>>> We are good with:
>>>>>
>>>>> -- >8 --
>>>>> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
>>>>> index 29fd9019b8..dcec09b6f9 100644
>>>>> --- a/pc-bios/s390-ccw/Makefile
>>>>> +++ b/pc-bios/s390-ccw/Makefile
>>>>> @@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>>>>>  quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
>>>>> $1, @$1))
>>>>>  cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
>>>>> /dev/null \
>>>>>               2>&1 && echo OK), $1, $2)
>>>>> +cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>>>>> +                >/dev/null 2>&1 && echo OK), $2, $3)
>>>>>
>>>>>  VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>>>>>  set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
>>>>> $(PATTERN) $1)))
>>>>> @@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
>>>>> menu.o \
>>>>>           virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o
>>>>> dasd-ipl.o
>>>>>
>>>>>  QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
>>>>> +QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS),
>>>>> -Wno-stringop-overflow)
>>>>>  QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
>>>>
>>>> I think you don't need the "cc-c-option" magic here. Just add the
>>>> -Wno-stringop-overflow. All supported versions of GCC and Clang
>>>> simply silently ignore unknown -Wno-something options (try e.g. "gcc
>>>> -Wno-yadayadayada" on the command line).
>>>
>>> Clang seems not to like it. It's always a mess to do anything for gcc
>>> and clang :-(
>
>I didn't know we could build s390-ccw with clang.
>
>Not with clang-12:
>
>clang version 12.0.0 (Fedora 12.0.0-0.3.rc1.fc34)
>
>warning: unknown warning option '-Wold-style-declaration'; did you mean
>'-Wout-of-line-declaration'? [-Wunknown-warning-option]
>warning: unknown warning option '-Wimplicit-fallthrough=2'; did you mean
>'-Wimplicit-fallthrough'? [-Wunknown-warning-option]
>warning: unknown warning option '-Wno-stringop-overflow'; did you mean
>'-Wno-shift-overflow'? [-Wunknown-warning-option]
>warning: unknown warning option '-Wold-style-declaration'; did you mean
>'-Wout-of-line-declaration'? [-Wunknown-warning-option]
>warning: unknown warning option '-Wimplicit-fallthrough=2'; did you mean
>'-Wimplicit-fallthrough'? [-Wunknown-warning-option]
>warning: unknown warning option '-Wno-stringop-overflow'; did you mean
>'-Wno-shift-overflow'? [-Wunknown-warning-option]
>error: unknown target CPU 'z900'
>note: valid target CPU values are: arch8, z10, arch9, z196, arch10,
>zEC12, arch11, z13, arch12, z14, arch13, z15

Ah, I didn't know that, I just tried the unknown -Wno-yadayadayada :-)

>
>>> Maybe we can set also `-Wno-unknown-warning-option`.
>>>
>>> $ clang -Wno-stringop-overflow -Werror main.c
>>> error: unknown warning option '-Wno-stringop-overflow'; did you mean
>>> '-Wno-shift-overflow'? [-Werror,-Wunknown-warning-option]
>>
>> D'oh, I was pretty sure that Clang behaves the same with regards to
>> -Wno-something, but seems I was wrong, sorry.

Np :-) I'm always confused between gcc and clang...

>>
>> So I think we should simply keep this v1 of Philippe's patch.
>>

Yep, I agree.

Thanks,
Stefano

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Christian Borntraeger]

On 23.04.21 08:40, Stefano Garzarella wrote:
> On Thu, Apr 22, 2021 at 06:54:21PM +0200, Philippe Mathieu-Daudé wrote:
>> On 4/22/21 6:07 PM, Thomas Huth wrote:
>>> On 22/04/2021 17.52, Stefano Garzarella wrote:
>>>> On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
>>>>> On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
>>>>>> On 4/22/21 2:41 PM, Christian Borntraeger wrote:
>>>>>>> On 22.04.21 13:47, Thomas Huth wrote:
>>>>>>>> On 22/04/2021 13.24, Philippe Mathieu-Daudé wrote:
>>>>>>>>> On 4/22/21 12:30 PM, Peter Maydell wrote:
>>>>>>>>>> On Thu, 22 Apr 2021 at 11:18, Daniel P. Berrangé
>>>>>>>>>> <berrange@redhat.com> wrote:
>>>>>>
>>>>>>>>> This silents the warning however:
>>>>>>>>>
>>>>>>>>> -- >8 --
>>>>>>>>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>>>>>>>>> index bcdc45732d..2dea399904 100644
>>>>>>>>> --- a/pc-bios/s390-ccw/libc.h
>>>>>>>>> +++ b/pc-bios/s390-ccw/libc.h
>>>>>>>>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>>>>>>>>   typedef unsigned int       uint32_t;
>>>>>>>>>   typedef unsigned long long uint64_t;
>>>>>>>>>
>>>>>>>>> +#pragma GCC diagnostic push
>>>>>>>>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>>>>>>>   static inline void *memset(void *s, int c, size_t n)
>>>>>>>>>   {
>>>>>>>>>       size_t i;
>>>>>>>>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c,
>>>>>>>>> size_t n)
>>>>>>>>>
>>>>>>>>>       return s;
>>>>>>>>>   }
>>>>>>>>> +#pragma GCC diagnostic pop
>>>>>>>>
>>>>>>>> Honestly, that compiler "bug" sounds like it could trigger at any
>>>>>>>> other spot in the bios code, too, since we are doing lots of direct
>>>>>>>> accesses to low memory there. I think it's likely best if we shut it
>>>>>>>> off with -Wno-stringop-overflow in the pc-bios/s390-ccw/Makefile ...
>>>>>>>> could you please try to add it there?
>>>>>>>
>>>>>>
>>>>>> We are good with:
>>>>>>
>>>>>> -- >8 --
>>>>>> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
>>>>>> index 29fd9019b8..dcec09b6f9 100644
>>>>>> --- a/pc-bios/s390-ccw/Makefile
>>>>>> +++ b/pc-bios/s390-ccw/Makefile
>>>>>> @@ -8,6 +8,9 @@ CFLAGS = -O2 -g
>>>>>>  quiet-command = $(if $(V),$1,$(if $(2),@printf "  %-7s %s\n" $2 $3 &&
>>>>>> $1, @$1))
>>>>>>  cc-option = $(if $(shell $(CC) $1 -S -o /dev/null -xc /dev/null >
>>>>>> /dev/null \
>>>>>>               2>&1 && echo OK), $1, $2)
>>>>>> +cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>>>>>> +                >/dev/null 2>&1 && echo OK), $2, $3)
>>>>>>
>>>>>>  VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.sh %.rc Kconfig% %.json.in
>>>>>>  set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath
>>>>>> $(PATTERN) $1)))
>>>>>> @@ -30,6 +33,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o
>>>>>> menu.o \
>>>>>>           virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o
>>>>>> dasd-ipl.o
>>>>>>
>>>>>>  QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
>>>>>> +QEMU_CFLAGS += $(call cc-c-option, $(QEMU_CFLAGS),
>>>>>> -Wno-stringop-overflow)
>>>>>>  QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks
>>>>>
>>>>> I think you don't need the "cc-c-option" magic here. Just add the
>>>>> -Wno-stringop-overflow. All supported versions of GCC and Clang
>>>>> simply silently ignore unknown -Wno-something options (try e.g. "gcc
>>>>> -Wno-yadayadayada" on the command line).
>>>>
>>>> Clang seems not to like it. It's always a mess to do anything for gcc
>>>> and clang :-(
>>
>> I didn't know we could build s390-ccw with clang.
>>
>> Not with clang-12:
>>
>> clang version 12.0.0 (Fedora 12.0.0-0.3.rc1.fc34)
>>
>> warning: unknown warning option '-Wold-style-declaration'; did you mean
>> '-Wout-of-line-declaration'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wimplicit-fallthrough=2'; did you mean
>> '-Wimplicit-fallthrough'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wno-stringop-overflow'; did you mean
>> '-Wno-shift-overflow'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wold-style-declaration'; did you mean
>> '-Wout-of-line-declaration'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wimplicit-fallthrough=2'; did you mean
>> '-Wimplicit-fallthrough'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wno-stringop-overflow'; did you mean
>> '-Wno-shift-overflow'? [-Wunknown-warning-option]
>> error: unknown target CPU 'z900'
>> note: valid target CPU values are: arch8, z10, arch9, z196, arch10,
>> zEC12, arch11, z13, arch12, z14, arch13, z15
> 
> Ah, I didn't know that, I just tried the unknown -Wno-yadayadayada :-)


We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
in the mean time can handle up to z13 and z10 is now also 13 years old.

Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)

[Thomas Huth]

On 23/04/2021 08.52, Christian Borntraeger wrote:
[...]
> We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
> in the mean time can handle up to z13 and z10 is now also 13 years old.

I'd really like to see us supporting Clang in the s390-ccw bios, too, since 
it provides additional useful compiler warnings ... but switching the -mz900 
to -mz10 here also means that we could not boot VMs anymore that use a CPU 
that is older than the z10...

Is anybody still using such old CPUs? Should we maybe deprecate all CPUs 
that are older than the z10 in QEMU? Alternatively, we could try to detect 
Clang in the Makefile, and only use -mz10 in that case and continue to use 
-mz900 in the other case...?

  Thomas

Re: Compiling the s390-ccw bios with clang

[Christian Borntraeger]

On 23.04.21 09:57, Thomas Huth wrote:
> On 23/04/2021 08.52, Christian Borntraeger wrote:
> [...]
>> We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
>> in the mean time can handle up to z13 and z10 is now also 13 years old.
> 
> I'd really like to see us supporting Clang in the s390-ccw bios, too, since it provides additional useful compiler warnings ... but switching the -mz900 to -mz10 here also means that we could not boot VMs anymore that use a CPU that is older than the z10...
> 
> Is anybody still using such old CPUs? Should we maybe deprecate all CPUs that are older than the z10 in QEMU? Alternatively, we could try to detect Clang in the Makefile, and only use -mz10 in that case and continue to use -mz900 in the other case...?

If we can make it "non-ugly" this is certainly the most unproblematic variant.

Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)

[Cornelia Huck]

On Fri, 23 Apr 2021 09:57:08 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 23/04/2021 08.52, Christian Borntraeger wrote:
> [...]
> > We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
> > in the mean time can handle up to z13 and z10 is now also 13 years old.  
> 
> I'd really like to see us supporting Clang in the s390-ccw bios, too, since 
> it provides additional useful compiler warnings ... but switching the -mz900 
> to -mz10 here also means that we could not boot VMs anymore that use a CPU 
> that is older than the z10...

We could still boot a kernel/initrd directly, couldn't we?

> 
> Is anybody still using such old CPUs? Should we maybe deprecate all CPUs 
> that are older than the z10 in QEMU? Alternatively, we could try to detect 
> Clang in the Makefile, and only use -mz10 in that case and continue to use 
> -mz900 in the other case...?

So, the issue with clang is that it compiles to at least a z10, right?
Any other issues we know about?

Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)

[Thomas Huth]

On 23/04/2021 10.07, Cornelia Huck wrote:
> On Fri, 23 Apr 2021 09:57:08 +0200
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> On 23/04/2021 08.52, Christian Borntraeger wrote:
>> [...]
>>> We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
>>> in the mean time can handle up to z13 and z10 is now also 13 years old.
>>
>> I'd really like to see us supporting Clang in the s390-ccw bios, too, since
>> it provides additional useful compiler warnings ... but switching the -mz900
>> to -mz10 here also means that we could not boot VMs anymore that use a CPU
>> that is older than the z10...
> 
> We could still boot a kernel/initrd directly, couldn't we?

Yes, but that will certainly require some documentation effort to make it 
clear to the users that they need to use "-kernel" in case they want to run 
an older guest...

>> Is anybody still using such old CPUs? Should we maybe deprecate all CPUs
>> that are older than the z10 in QEMU? Alternatively, we could try to detect
>> Clang in the Makefile, and only use -mz10 in that case and continue to use
>> -mz900 in the other case...?
> 
> So, the issue with clang is that it compiles to at least a z10, right?

Right, Clang does not support anything that is older than a z10.

> Any other issues we know about?

There are some compiler warnings, and at least network booting seems to be 
broken... that certainly needs some investigation first...

  Thomas

Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)

[Daniel P. Berrangé]

On Fri, Apr 23, 2021 at 10:22:28AM +0200, Thomas Huth wrote:
> On 23/04/2021 10.07, Cornelia Huck wrote:
> > On Fri, 23 Apr 2021 09:57:08 +0200
> > Thomas Huth <thuth@redhat.com> wrote:
> > 
> > > On 23/04/2021 08.52, Christian Borntraeger wrote:
> > > [...]
> > > > We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
> > > > in the mean time can handle up to z13 and z10 is now also 13 years old.
> > > 
> > > I'd really like to see us supporting Clang in the s390-ccw bios, too, since
> > > it provides additional useful compiler warnings ... but switching the -mz900
> > > to -mz10 here also means that we could not boot VMs anymore that use a CPU
> > > that is older than the z10...
> > 
> > We could still boot a kernel/initrd directly, couldn't we?
> 
> Yes, but that will certainly require some documentation effort to make it
> clear to the users that they need to use "-kernel" in case they want to run
> an older guest...
> 
> > > Is anybody still using such old CPUs? Should we maybe deprecate all CPUs
> > > that are older than the z10 in QEMU? Alternatively, we could try to detect
> > > Clang in the Makefile, and only use -mz10 in that case and continue to use
> > > -mz900 in the other case...?
> > 
> > So, the issue with clang is that it compiles to at least a z10, right?
> 
> Right, Clang does not support anything that is older than a z10.

IIUC, according to wikipedia

   - z10 series was introduced in 2008
   - z900 series was introduced in 2000

Even the z10 is well older than the oldest OS platform we support.

Though I presume people keep mainframes deployed for longer than commodity
x86 hardware, it doesn't seem too unreasonable to say z10 is the oldest
we'll support.

IIUC, downstreams like RHEL already require even newer hadware than z10


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)

[Thomas Huth]

On 23/04/2021 10.47, Daniel P. Berrangé wrote:
> On Fri, Apr 23, 2021 at 10:22:28AM +0200, Thomas Huth wrote:
>> On 23/04/2021 10.07, Cornelia Huck wrote:
>>> On Fri, 23 Apr 2021 09:57:08 +0200
>>> Thomas Huth <thuth@redhat.com> wrote:
>>>
>>>> On 23/04/2021 08.52, Christian Borntraeger wrote:
>>>> [...]
>>>>> We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
>>>>> in the mean time can handle up to z13 and z10 is now also 13 years old.
>>>>
>>>> I'd really like to see us supporting Clang in the s390-ccw bios, too, since
>>>> it provides additional useful compiler warnings ... but switching the -mz900
>>>> to -mz10 here also means that we could not boot VMs anymore that use a CPU
>>>> that is older than the z10...
>>>
>>> We could still boot a kernel/initrd directly, couldn't we?
>>
>> Yes, but that will certainly require some documentation effort to make it
>> clear to the users that they need to use "-kernel" in case they want to run
>> an older guest...
>>
>>>> Is anybody still using such old CPUs? Should we maybe deprecate all CPUs
>>>> that are older than the z10 in QEMU? Alternatively, we could try to detect
>>>> Clang in the Makefile, and only use -mz10 in that case and continue to use
>>>> -mz900 in the other case...?
>>>
>>> So, the issue with clang is that it compiles to at least a z10, right?
>>
>> Right, Clang does not support anything that is older than a z10.
> 
> IIUC, according to wikipedia
> 
>     - z10 series was introduced in 2008
>     - z900 series was introduced in 2000
> 
> Even the z10 is well older than the oldest OS platform we support.
> 
> Though I presume people keep mainframes deployed for longer than commodity
> x86 hardware, it doesn't seem too unreasonable to say z10 is the oldest
> we'll support.
Well, we're talking about *guest* support here. So with that argumentation, 
we could also remove support for old CPUs like "486" or "SandyBridge" from 
qemu-system-x86_64 ... should we maybe also start the deprecation there?

  Thomas

Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)

[Daniel P. Berrangé]

On Fri, Apr 23, 2021 at 10:52:35AM +0200, Thomas Huth wrote:
> On 23/04/2021 10.47, Daniel P. Berrangé wrote:
> > On Fri, Apr 23, 2021 at 10:22:28AM +0200, Thomas Huth wrote:
> > > On 23/04/2021 10.07, Cornelia Huck wrote:
> > > > On Fri, 23 Apr 2021 09:57:08 +0200
> > > > Thomas Huth <thuth@redhat.com> wrote:
> > > > 
> > > > > On 23/04/2021 08.52, Christian Borntraeger wrote:
> > > > > [...]
> > > > > > We can of course discuss if we compile the BIOS for z10 instead of z900. TCG
> > > > > > in the mean time can handle up to z13 and z10 is now also 13 years old.
> > > > > 
> > > > > I'd really like to see us supporting Clang in the s390-ccw bios, too, since
> > > > > it provides additional useful compiler warnings ... but switching the -mz900
> > > > > to -mz10 here also means that we could not boot VMs anymore that use a CPU
> > > > > that is older than the z10...
> > > > 
> > > > We could still boot a kernel/initrd directly, couldn't we?
> > > 
> > > Yes, but that will certainly require some documentation effort to make it
> > > clear to the users that they need to use "-kernel" in case they want to run
> > > an older guest...
> > > 
> > > > > Is anybody still using such old CPUs? Should we maybe deprecate all CPUs
> > > > > that are older than the z10 in QEMU? Alternatively, we could try to detect
> > > > > Clang in the Makefile, and only use -mz10 in that case and continue to use
> > > > > -mz900 in the other case...?
> > > > 
> > > > So, the issue with clang is that it compiles to at least a z10, right?
> > > 
> > > Right, Clang does not support anything that is older than a z10.
> > 
> > IIUC, according to wikipedia
> > 
> >     - z10 series was introduced in 2008
> >     - z900 series was introduced in 2000
> > 
> > Even the z10 is well older than the oldest OS platform we support.
> > 
> > Though I presume people keep mainframes deployed for longer than commodity
> > x86 hardware, it doesn't seem too unreasonable to say z10 is the oldest
> > we'll support.
>
> Well, we're talking about *guest* support here. So with that argumentation,
> we could also remove support for old CPUs like "486" or "SandyBridge" from
> qemu-system-x86_64 ... should we maybe also start the deprecation there?

Oh true, I forgot it would have implications for usability of the -cpu
flag choices, I was only thinking about the guest OS, as you can sitll
use a guest OS compiled for z900 even if the BIOS is targetting z10.

So need to compile BIOS with z900 is effectively equivalent to the need
to compile x86 BIOS for oldest generation CPU.

Downstream distros have the choice to limit what CPUs they wish to
support, but upstream if QEMU targets legacy emulation use cases, then
we want to support all CPUs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Daniel P. Berrangé]

On Thu, Apr 22, 2021 at 01:24:30PM +0200, Philippe Mathieu-Daudé wrote:
> This silents the warning however:
> 
> -- >8 --
> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
> index bcdc45732d..2dea399904 100644
> --- a/pc-bios/s390-ccw/libc.h
> +++ b/pc-bios/s390-ccw/libc.h
> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>  typedef unsigned int       uint32_t;
>  typedef unsigned long long uint64_t;
> 
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>  static inline void *memset(void *s, int c, size_t n)
>  {
>      size_t i;
> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
> 
>      return s;
>  }
> +#pragma GCC diagnostic pop

I wonder if it works if you put the pragma around the specific
caller, as that would make the scope more limited so we can still
see valid bugs elsewhere

> 
>  static inline void *memcpy(void *s1, const void *s2, size_t n)
>  {
> ---
> 
> Oddly this code doesn't emit any warning:

Let me correct that for you

  s/doesn't emit any warning/doesn't emit any warning *yet*/

compilers get more strict all the time. The memcmp is just
a memory read, however, while memset is a write, so less
severe

>   if (!memcmp((char *)S390EP, "S390EP", 6)) {
>   ...

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[Philippe Mathieu-Daudé]

On 4/22/21 1:48 PM, Daniel P. Berrangé wrote:
> On Thu, Apr 22, 2021 at 01:24:30PM +0200, Philippe Mathieu-Daudé wrote:
>> This silents the warning however:
>>
>> -- >8 --
>> diff --git a/pc-bios/s390-ccw/libc.h b/pc-bios/s390-ccw/libc.h
>> index bcdc45732d..2dea399904 100644
>> --- a/pc-bios/s390-ccw/libc.h
>> +++ b/pc-bios/s390-ccw/libc.h
>> @@ -19,6 +19,8 @@ typedef unsigned short     uint16_t;
>>  typedef unsigned int       uint32_t;
>>  typedef unsigned long long uint64_t;
>>
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
>>  static inline void *memset(void *s, int c, size_t n)
>>  {
>>      size_t i;
>> @@ -30,6 +32,7 @@ static inline void *memset(void *s, int c, size_t n)
>>
>>      return s;
>>  }
>> +#pragma GCC diagnostic pop
> 
> I wonder if it works if you put the pragma around the specific
> caller, as that would make the scope more limited so we can still
> see valid bugs elsewhere

No, this doesn't silence it:

-- >8 --
diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
@@ -182,7 +182,10 @@ static void boot_setup(void)
      * Clear out any potential S390EP magic (see jump_to_low_kernel()),
      * so we don't taint our decision-making process during a reboot.
      */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
     memset((char *)S390EP, 0, 6);
+#pragma GCC diagnostic pop

     have_iplb = store_iplb(&iplb);
 }
---

> 
>>
>>  static inline void *memcpy(void *s1, const void *s2, size_t n)
>>  {
>> ---
>>
>> Oddly this code doesn't emit any warning:
> 
> Let me correct that for you
> 
>   s/doesn't emit any warning/doesn't emit any warning *yet*/
> 
> compilers get more strict all the time. The memcmp is just
> a memory read, however, while memset is a write, so less
> severe

OK :)

>>   if (!memcmp((char *)S390EP, "S390EP", 6)) {
>>   ...
> 
> Regards,
> Daniel
>