* Re: disable -Warray-bounds in libgo (PR 101374)
2021-07-09 6:16 ` Richard Biener
@ 2021-07-09 13:19 ` Maxim Kuvyrkov
2021-07-09 19:46 ` Martin Sebor
2021-07-09 16:37 ` Martin Sebor
` (2 subsequent siblings)
3 siblings, 1 reply; 11+ messages in thread
From: Maxim Kuvyrkov @ 2021-07-09 13:19 UTC (permalink / raw)
To: Martin Sebor
Cc: Richard Biener, gcc-patches, Ian Lance Taylor, Richard Henderson
> On 9 Jul 2021, at 09:16, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> Hi Ian,
>>
>> Yesterday's enhancement to -Warray-bounds has exposed a couple of
>> issues in libgo where the code writes into an invalid constant
>> address that the warning is designed to flag.
>>
>> On the assumption that those invalid addresses are deliberate,
>> the attached patch suppresses these instances by using #pragma
>> GCC diagnostic but I don't think I'm supposed to commit it (at
>> least Git won't let me). To avoid Go bootstrap failures please
>> either apply the patch or otherwise suppress the warning (e.g.,
>> by using a volatile pointer temporary).
>
> Btw, I don't think we should diagnose things like
>
> *(int*)0x21 = 0x21;
>
> when somebody literally writes that he'll be just annoyed by diagnostics.
And we have an assortment of similar cases in 32-bit ARM kernel-page helpers.
At the moment building libatomic for arm-linux-gnueabihf fails with:
===
In function ‘select_test_and_set_8’,
inlined from ‘select_test_and_set_8’ at /home/tcwg-buildslave/workspace/tcwg-dev-build/snapshots/gcc.git~master/libatomic/tas_n.c:115:1:
/home/tcwg-buildslave/workspace/tcwg-dev-build/snapshots/gcc.git~master/libatomic/config/linux/arm/host-config.h:42:34: error: array subscript 0 is outside array bounds of ‘unsigned int[0]’ [-Werror=array-bounds]
42 | #define __kernel_helper_version (*(unsigned int *)0xffff0ffc)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
===
In libatomic/config/linux/arm/host-config.h we have:
===
/* Kernel helper for 32-bit compare-and-exchange. */
typedef int (__kernel_cmpxchg_t) (UWORD oldval, UWORD newval, UWORD *ptr);
#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0xffff0fc0)
/* Kernel helper for 64-bit compare-and-exchange. */
typedef int (__kernel_cmpxchg64_t) (const U_8 * oldval, const U_8 * newval,
U_8 *ptr);
#define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *) 0xffff0f60)
/* Kernel helper for memory barrier. */
typedef void (__kernel_dmb_t) (void);
#define __kernel_dmb (*(__kernel_dmb_t *) 0xffff0fa0)
/* Kernel helper page version number. */
#define __kernel_helper_version (*(unsigned int *)0xffff0ffc)
===
--
Maxim Kuvyrkov
https://www.linaro.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: disable -Warray-bounds in libgo (PR 101374)
2021-07-09 13:19 ` Maxim Kuvyrkov
@ 2021-07-09 19:46 ` Martin Sebor
0 siblings, 0 replies; 11+ messages in thread
From: Martin Sebor @ 2021-07-09 19:46 UTC (permalink / raw)
To: Maxim Kuvyrkov
Cc: Richard Biener, gcc-patches, Ian Lance Taylor, Richard Henderson
On 7/9/21 7:19 AM, Maxim Kuvyrkov wrote:
>> On 9 Jul 2021, at 09:16, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>
>> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> Hi Ian,
>>>
>>> Yesterday's enhancement to -Warray-bounds has exposed a couple of
>>> issues in libgo where the code writes into an invalid constant
>>> address that the warning is designed to flag.
>>>
>>> On the assumption that those invalid addresses are deliberate,
>>> the attached patch suppresses these instances by using #pragma
>>> GCC diagnostic but I don't think I'm supposed to commit it (at
>>> least Git won't let me). To avoid Go bootstrap failures please
>>> either apply the patch or otherwise suppress the warning (e.g.,
>>> by using a volatile pointer temporary).
>>
>> Btw, I don't think we should diagnose things like
>>
>> *(int*)0x21 = 0x21;
>>
>> when somebody literally writes that he'll be just annoyed by diagnostics.
>
> And we have an assortment of similar cases in 32-bit ARM kernel-page helpers.
>
> At the moment building libatomic for arm-linux-gnueabihf fails with:
> ===
> In function ‘select_test_and_set_8’,
> inlined from ‘select_test_and_set_8’ at /home/tcwg-buildslave/workspace/tcwg-dev-build/snapshots/gcc.git~master/libatomic/tas_n.c:115:1:
> /home/tcwg-buildslave/workspace/tcwg-dev-build/snapshots/gcc.git~master/libatomic/config/linux/arm/host-config.h:42:34: error: array subscript 0 is outside array bounds of ‘unsigned int[0]’ [-Werror=array-bounds]
> 42 | #define __kernel_helper_version (*(unsigned int *)0xffff0ffc)
> | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ===
>
> In libatomic/config/linux/arm/host-config.h we have:
> ===
> /* Kernel helper for 32-bit compare-and-exchange. */
> typedef int (__kernel_cmpxchg_t) (UWORD oldval, UWORD newval, UWORD *ptr);
> #define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0xffff0fc0)
>
> /* Kernel helper for 64-bit compare-and-exchange. */
> typedef int (__kernel_cmpxchg64_t) (const U_8 * oldval, const U_8 * newval,
> U_8 *ptr);
> #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *) 0xffff0f60)
>
> /* Kernel helper for memory barrier. */
> typedef void (__kernel_dmb_t) (void);
> #define __kernel_dmb (*(__kernel_dmb_t *) 0xffff0fa0)
>
> /* Kernel helper page version number. */
> #define __kernel_helper_version (*(unsigned int *)0xffff0ffc)
> ===
This failure is tracked in pr101379. I have added an untested POC
patch with a possible way to avoid the warning. Other approaches
are possible (I mention some in my comment on the bug) but they
are limited by the exposure of the constant address using macros.
Hiding them behind APIs instead would make it possible to suppress
the warnings via #pragma GCC diagnostic. Alternatively, making
the addresses extern const variables would hide the constants from
the warning altogether.
With a suitable attribute an API or variable could also describe
the size of the object. The AVR back end, for example, has two
attributes for hardwired addresses: io and address. One of them
(or another one like it) could be made the target-indendependent
way to declare global variables of any type at fixed addresses,
e.g., like so:
extern __attribute__ ((address (0xffff0fc0))) __kernel_cmpxchg64_t
__kernel_cmpxchg;
Martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: disable -Warray-bounds in libgo (PR 101374)
2021-07-09 6:16 ` Richard Biener
2021-07-09 13:19 ` Maxim Kuvyrkov
@ 2021-07-09 16:37 ` Martin Sebor
2021-07-10 2:49 ` Ian Lance Taylor
2021-07-13 18:30 ` Dimitar Dimitrov
3 siblings, 0 replies; 11+ messages in thread
From: Martin Sebor @ 2021-07-09 16:37 UTC (permalink / raw)
To: Richard Biener; +Cc: Ian Lance Taylor, gcc-patches
On 7/9/21 12:16 AM, Richard Biener wrote:
> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> Hi Ian,
>>
>> Yesterday's enhancement to -Warray-bounds has exposed a couple of
>> issues in libgo where the code writes into an invalid constant
>> address that the warning is designed to flag.
>>
>> On the assumption that those invalid addresses are deliberate,
>> the attached patch suppresses these instances by using #pragma
>> GCC diagnostic but I don't think I'm supposed to commit it (at
>> least Git won't let me). To avoid Go bootstrap failures please
>> either apply the patch or otherwise suppress the warning (e.g.,
>> by using a volatile pointer temporary).
>
> Btw, I don't think we should diagnose things like
>
> *(int*)0x21 = 0x21;
>
> when somebody literally writes that he'll be just annoyed by diagnostics.
>
> Of course the above might be able to use __builtin_trap (); - it looks
> like it is placed where control flow should never end, kind of a
> __builtin_unreachable (), which means abort () might do as well.
I agree that the literal case isn't interesting. At the time
the warnings run the distinction between a nonnull literal and
one derived from a null has been lost. I'm hoping to replace
this with an early pass to detect null pointer arithmetic.
Martin
>
> Richard.
>
>> Thanks
>> Martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: disable -Warray-bounds in libgo (PR 101374)
2021-07-09 6:16 ` Richard Biener
2021-07-09 13:19 ` Maxim Kuvyrkov
2021-07-09 16:37 ` Martin Sebor
@ 2021-07-10 2:49 ` Ian Lance Taylor
2021-07-13 18:30 ` Dimitar Dimitrov
3 siblings, 0 replies; 11+ messages in thread
From: Ian Lance Taylor @ 2021-07-10 2:49 UTC (permalink / raw)
To: Richard Biener; +Cc: Martin Sebor, gcc-patches, gofrontend-dev
[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]
On Thu, Jul 8, 2021 at 11:16 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > Hi Ian,
> >
> > Yesterday's enhancement to -Warray-bounds has exposed a couple of
> > issues in libgo where the code writes into an invalid constant
> > address that the warning is designed to flag.
> >
> > On the assumption that those invalid addresses are deliberate,
> > the attached patch suppresses these instances by using #pragma
> > GCC diagnostic but I don't think I'm supposed to commit it (at
> > least Git won't let me). To avoid Go bootstrap failures please
> > either apply the patch or otherwise suppress the warning (e.g.,
> > by using a volatile pointer temporary).
>
> Btw, I don't think we should diagnose things like
>
> *(int*)0x21 = 0x21;
>
> when somebody literally writes that he'll be just annoyed by diagnostics.
>
> Of course the above might be able to use __builtin_trap (); - it looks
> like it is placed where control flow should never end, kind of a
> __builtin_unreachable (), which means abort () might do as well.
I agree. While this code is certainly intentional, abort will work
just as well in practice. I committed the following to change it.
Ian
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1322 bytes --]
a15210699cbc60bc9ed077549dcd5288a295f42c
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index ab1384d698b..4d0f44f2dd2 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-01cb2b5e69a2d08ef3cc1ea023c22ed9b79f5114
+adcf10890833026437a94da54934ce50c0018309
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
diff --git a/libgo/runtime/proc.c b/libgo/runtime/proc.c
index 38bf7a6b255..3a30748d329 100644
--- a/libgo/runtime/proc.c
+++ b/libgo/runtime/proc.c
@@ -594,7 +594,7 @@ runtime_mstart(void *arg)
gp->entry = nil;
gp->param = nil;
__builtin_call_with_static_chain(pfn(gp1), fv);
- *(int*)0x21 = 0x21;
+ abort();
}
if(mp->exiting) {
@@ -662,7 +662,7 @@ setGContext(void)
gp->entry = nil;
gp->param = nil;
__builtin_call_with_static_chain(pfn(gp1), fv);
- *(int*)0x22 = 0x22;
+ abort();
}
}
diff --git a/libgo/runtime/runtime_c.c b/libgo/runtime/runtime_c.c
index 18222c14465..bc920a5d406 100644
--- a/libgo/runtime/runtime_c.c
+++ b/libgo/runtime/runtime_c.c
@@ -116,7 +116,7 @@ runtime_signalstack(byte *p, uintptr n)
if(p == nil)
st.ss_flags = SS_DISABLE;
if(sigaltstack(&st, nil) < 0)
- *(int *)0xf1 = 0xf1;
+ abort();
}
int32 go_open(char *, int32, int32)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: disable -Warray-bounds in libgo (PR 101374)
2021-07-09 6:16 ` Richard Biener
` (2 preceding siblings ...)
2021-07-10 2:49 ` Ian Lance Taylor
@ 2021-07-13 18:30 ` Dimitar Dimitrov
3 siblings, 0 replies; 11+ messages in thread
From: Dimitar Dimitrov @ 2021-07-13 18:30 UTC (permalink / raw)
To: Richard Biener; +Cc: Martin Sebor, gcc-patches, Ian Lance Taylor
On Fri, Jul 09, 2021 at 08:16:24AM +0200, Richard Biener via Gcc-patches wrote:
> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > Hi Ian,
> >
> > Yesterday's enhancement to -Warray-bounds has exposed a couple of
> > issues in libgo where the code writes into an invalid constant
> > address that the warning is designed to flag.
> >
> > On the assumption that those invalid addresses are deliberate,
> > the attached patch suppresses these instances by using #pragma
> > GCC diagnostic but I don't think I'm supposed to commit it (at
> > least Git won't let me). To avoid Go bootstrap failures please
> > either apply the patch or otherwise suppress the warning (e.g.,
> > by using a volatile pointer temporary).
>
> Btw, I don't think we should diagnose things like
>
> *(int*)0x21 = 0x21;
>
> when somebody literally writes that he'll be just annoyed by diagnostics.
I agree. This will raise a lot of noise for embedded targets.
Similar constructs are used extensively in pretty much any microcontroller
project to define macros to access I/O special-function addresses.
A few random examples:
http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/include/avr/sfr_defs.h?view=markup#l128
https://sourceforge.net/p/mspgcc/msp430mcu/ci/master/tree/upstream/cc430f5123.h#l2141
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/RTOS/RTX/SRC/rt_HAL_CM.h#L138
Regards,
Dimitar
>
> Of course the above might be able to use __builtin_trap (); - it looks
> like it is placed where control flow should never end, kind of a
> __builtin_unreachable (), which means abort () might do as well.
>
> Richard.
>
> > Thanks
> > Martin
^ permalink raw reply [flat|nested] 11+ messages in thread