* s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
@ 2021-04-22 4:18 Philippe Mathieu-Daudé
2021-04-22 4:47 ` Thomas Huth
0 siblings, 1 reply; 25+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-22 4:18 UTC (permalink / raw)
To: Thomas Huth, Daniel P . Berrange, Stefano Garzarella
Cc: qemu-s390x, Richard Henderson, qemu-devel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 4:18 s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Philippe Mathieu-Daudé
@ 2021-04-22 4:47 ` Thomas Huth
2021-04-22 6:04 ` Christian Borntraeger
2021-04-22 10:15 ` Daniel P. Berrangé
0 siblings, 2 replies; 25+ messages in thread
From: Thomas Huth @ 2021-04-22 4:47 UTC (permalink / raw)
To: Philippe Mathieu-Daudé,
Daniel P . Berrange, Stefano Garzarella, Christian Borntraeger,
Cornelia Huck, Janosch Frank
Cc: qemu-s390x, Richard Henderson, qemu-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 4:47 ` Thomas Huth
@ 2021-04-22 6:04 ` Christian Borntraeger
2021-04-22 10:15 ` Daniel P. Berrangé
1 sibling, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2021-04-22 6:04 UTC (permalink / raw)
To: Thomas Huth, Philippe Mathieu-Daudé,
Daniel P . Berrange, Stefano Garzarella, Cornelia Huck,
Janosch Frank
Cc: qemu-s390x, Richard Henderson, qemu-devel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 4:47 ` Thomas Huth
2021-04-22 6:04 ` Christian Borntraeger
@ 2021-04-22 10:15 ` Daniel P. Berrangé
2021-04-22 10:30 ` Peter Maydell
1 sibling, 1 reply; 25+ messages in thread
From: Daniel P. Berrangé @ 2021-04-22 10:15 UTC (permalink / raw)
To: Thomas Huth
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x, Philippe Mathieu-Daudé,
Stefano Garzarella
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 :|
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 10:15 ` Daniel P. Berrangé
@ 2021-04-22 10:30 ` Peter Maydell
2021-04-22 11:24 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 25+ messages in thread
From: Peter Maydell @ 2021-04-22 10:30 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Thomas Huth, Janosch Frank, Cornelia Huck, Richard Henderson,
qemu-devel, Christian Borntraeger, qemu-s390x,
Philippe Mathieu-Daudé,
Stefano Garzarella
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 10:30 ` Peter Maydell
@ 2021-04-22 11:24 ` Philippe Mathieu-Daudé
2021-04-22 11:47 ` Thomas Huth
2021-04-22 11:48 ` s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Daniel P. Berrangé
0 siblings, 2 replies; 25+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-22 11:24 UTC (permalink / raw)
To: Thomas Huth, Peter Maydell, Daniel P. Berrangé,
Christian Borntraeger
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x, Stefano Garzarella
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.
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 11:24 ` Philippe Mathieu-Daudé
@ 2021-04-22 11:47 ` Thomas Huth
2021-04-22 12:41 ` Christian Borntraeger
2021-04-22 11:48 ` s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Daniel P. Berrangé
1 sibling, 1 reply; 25+ messages in thread
From: Thomas Huth @ 2021-04-22 11:47 UTC (permalink / raw)
To: Philippe Mathieu-Daudé,
Peter Maydell, Daniel P. Berrangé,
Christian Borntraeger
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x, Stefano Garzarella
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 11:24 ` Philippe Mathieu-Daudé
2021-04-22 11:47 ` Thomas Huth
@ 2021-04-22 11:48 ` Daniel P. Berrangé
2021-04-22 14:34 ` Philippe Mathieu-Daudé
1 sibling, 1 reply; 25+ messages in thread
From: Daniel P. Berrangé @ 2021-04-22 11:48 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Peter Maydell, Thomas Huth, Janosch Frank, Cornelia Huck,
Richard Henderson, qemu-devel, Christian Borntraeger, qemu-s390x,
Stefano Garzarella
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 :|
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 11:47 ` Thomas Huth
@ 2021-04-22 12:41 ` Christian Borntraeger
2021-04-22 14:31 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 25+ messages in thread
From: Christian Borntraeger @ 2021-04-22 12:41 UTC (permalink / raw)
To: Thomas Huth, Philippe Mathieu-Daudé,
Peter Maydell, Daniel P. Berrangé
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x, Stefano Garzarella
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 12:41 ` Christian Borntraeger
@ 2021-04-22 14:31 ` Philippe Mathieu-Daudé
2021-04-22 15:38 ` Thomas Huth
0 siblings, 1 reply; 25+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-22 14:31 UTC (permalink / raw)
To: Christian Borntraeger, Thomas Huth, Peter Maydell,
Daniel P. Berrangé
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x, Stefano Garzarella
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.
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 11:48 ` s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Daniel P. Berrangé
@ 2021-04-22 14:34 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 25+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-22 14:34 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, Thomas Huth, Janosch Frank, Cornelia Huck,
Richard Henderson, qemu-devel, Christian Borntraeger, qemu-s390x,
Stefano Garzarella
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
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 14:31 ` Philippe Mathieu-Daudé
@ 2021-04-22 15:38 ` Thomas Huth
2021-04-22 15:43 ` Philippe Mathieu-Daudé
2021-04-22 15:52 ` Stefano Garzarella
0 siblings, 2 replies; 25+ messages in thread
From: Thomas Huth @ 2021-04-22 15:38 UTC (permalink / raw)
To: Philippe Mathieu-Daudé,
Christian Borntraeger, Peter Maydell, Daniel P. Berrangé
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x, Stefano Garzarella
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 15:38 ` Thomas Huth
@ 2021-04-22 15:43 ` Philippe Mathieu-Daudé
2021-04-22 15:52 ` Stefano Garzarella
1 sibling, 0 replies; 25+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-22 15:43 UTC (permalink / raw)
To: Thomas Huth, Christian Borntraeger, Peter Maydell,
Daniel P. Berrangé
Cc: Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x, Stefano Garzarella
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 :)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 15:38 ` Thomas Huth
2021-04-22 15:43 ` Philippe Mathieu-Daudé
@ 2021-04-22 15:52 ` Stefano Garzarella
2021-04-22 16:07 ` Thomas Huth
1 sibling, 1 reply; 25+ messages in thread
From: Stefano Garzarella @ 2021-04-22 15:52 UTC (permalink / raw)
To: Thomas Huth
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x, Philippe Mathieu-Daudé
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 15:52 ` Stefano Garzarella
@ 2021-04-22 16:07 ` Thomas Huth
2021-04-22 16:54 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Huth @ 2021-04-22 16:07 UTC (permalink / raw)
To: Stefano Garzarella
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x, Philippe Mathieu-Daudé
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 16:07 ` Thomas Huth
@ 2021-04-22 16:54 ` Philippe Mathieu-Daudé
2021-04-23 6:40 ` Stefano Garzarella
0 siblings, 1 reply; 25+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-22 16:54 UTC (permalink / raw)
To: Thomas Huth, Stefano Garzarella
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-22 16:54 ` Philippe Mathieu-Daudé
@ 2021-04-23 6:40 ` Stefano Garzarella
2021-04-23 6:52 ` Christian Borntraeger
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Garzarella @ 2021-04-23 6:40 UTC (permalink / raw)
To: Thomas Huth, Philippe Mathieu-Daudé
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2021-04-23 6:40 ` Stefano Garzarella
@ 2021-04-23 6:52 ` Christian Borntraeger
2021-04-23 7:57 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Thomas Huth
0 siblings, 1 reply; 25+ messages in thread
From: Christian Borntraeger @ 2021-04-23 6:52 UTC (permalink / raw)
To: Stefano Garzarella, Thomas Huth, Philippe Mathieu-Daudé
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)
2021-04-23 6:52 ` Christian Borntraeger
@ 2021-04-23 7:57 ` Thomas Huth
2021-04-23 8:05 ` Compiling the s390-ccw bios with clang Christian Borntraeger
2021-04-23 8:07 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Cornelia Huck
0 siblings, 2 replies; 25+ messages in thread
From: Thomas Huth @ 2021-04-23 7:57 UTC (permalink / raw)
To: Christian Borntraeger, Stefano Garzarella, Philippe Mathieu-Daudé
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling the s390-ccw bios with clang
2021-04-23 7:57 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Thomas Huth
@ 2021-04-23 8:05 ` Christian Borntraeger
2021-04-23 8:07 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Cornelia Huck
1 sibling, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2021-04-23 8:05 UTC (permalink / raw)
To: Thomas Huth, Stefano Garzarella, Philippe Mathieu-Daudé
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Cornelia Huck, Richard Henderson, qemu-devel,
qemu-s390x
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)
2021-04-23 7:57 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Thomas Huth
2021-04-23 8:05 ` Compiling the s390-ccw bios with clang Christian Borntraeger
@ 2021-04-23 8:07 ` Cornelia Huck
2021-04-23 8:22 ` Thomas Huth
1 sibling, 1 reply; 25+ messages in thread
From: Cornelia Huck @ 2021-04-23 8:07 UTC (permalink / raw)
To: Thomas Huth
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x, Philippe Mathieu-Daudé,
Stefano Garzarella
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?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)
2021-04-23 8:07 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Cornelia Huck
@ 2021-04-23 8:22 ` Thomas Huth
2021-04-23 8:47 ` Daniel P. Berrangé
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Huth @ 2021-04-23 8:22 UTC (permalink / raw)
To: Cornelia Huck
Cc: Peter Maydell, Daniel P. Berrangé,
Janosch Frank, Richard Henderson, qemu-devel,
Christian Borntraeger, qemu-s390x, Philippe Mathieu-Daudé,
Stefano Garzarella
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)
2021-04-23 8:22 ` Thomas Huth
@ 2021-04-23 8:47 ` Daniel P. Berrangé
2021-04-23 8:52 ` Thomas Huth
0 siblings, 1 reply; 25+ messages in thread
From: Daniel P. Berrangé @ 2021-04-23 8:47 UTC (permalink / raw)
To: Thomas Huth
Cc: Peter Maydell, Janosch Frank, Cornelia Huck, Richard Henderson,
qemu-devel, Christian Borntraeger, qemu-s390x,
Philippe Mathieu-Daudé,
Stefano Garzarella
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 :|
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)
2021-04-23 8:47 ` Daniel P. Berrangé
@ 2021-04-23 8:52 ` Thomas Huth
2021-04-23 9:00 ` Daniel P. Berrangé
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Huth @ 2021-04-23 8:52 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, Janosch Frank, Cornelia Huck, Richard Henderson,
qemu-devel, Christian Borntraeger, qemu-s390x,
Philippe Mathieu-Daudé,
Stefano Garzarella
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0)
2021-04-23 8:52 ` Thomas Huth
@ 2021-04-23 9:00 ` Daniel P. Berrangé
0 siblings, 0 replies; 25+ messages in thread
From: Daniel P. Berrangé @ 2021-04-23 9:00 UTC (permalink / raw)
To: Thomas Huth
Cc: Peter Maydell, Janosch Frank, Cornelia Huck, Richard Henderson,
qemu-devel, Christian Borntraeger, qemu-s390x,
Philippe Mathieu-Daudé,
Stefano Garzarella
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 :|
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2021-04-23 9:02 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-22 4:18 s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Philippe Mathieu-Daudé
2021-04-22 4:47 ` Thomas Huth
2021-04-22 6:04 ` Christian Borntraeger
2021-04-22 10:15 ` Daniel P. Berrangé
2021-04-22 10:30 ` Peter Maydell
2021-04-22 11:24 ` Philippe Mathieu-Daudé
2021-04-22 11:47 ` Thomas Huth
2021-04-22 12:41 ` Christian Borntraeger
2021-04-22 14:31 ` Philippe Mathieu-Daudé
2021-04-22 15:38 ` Thomas Huth
2021-04-22 15:43 ` Philippe Mathieu-Daudé
2021-04-22 15:52 ` Stefano Garzarella
2021-04-22 16:07 ` Thomas Huth
2021-04-22 16:54 ` Philippe Mathieu-Daudé
2021-04-23 6:40 ` Stefano Garzarella
2021-04-23 6:52 ` Christian Borntraeger
2021-04-23 7:57 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Thomas Huth
2021-04-23 8:05 ` Compiling the s390-ccw bios with clang Christian Borntraeger
2021-04-23 8:07 ` Compiling the s390-ccw bios with clang (was: Re: s390-ccw: warning: writing 1 byte into a region of size 0) Cornelia Huck
2021-04-23 8:22 ` Thomas Huth
2021-04-23 8:47 ` Daniel P. Berrangé
2021-04-23 8:52 ` Thomas Huth
2021-04-23 9:00 ` Daniel P. Berrangé
2021-04-22 11:48 ` s390-ccw: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Daniel P. Berrangé
2021-04-22 14:34 ` Philippe Mathieu-Daudé
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.