From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nWsyK-0000rf-PT for mharc-grub-devel@gnu.org; Wed, 23 Mar 2022 00:51:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWsyJ-0000rW-Lx for grub-devel@gnu.org; Wed, 23 Mar 2022 00:51:47 -0400 Received: from de-smtp-delivery-102.mimecast.com ([194.104.111.102]:21843) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWsyG-0008Eu-Qj for grub-devel@gnu.org; Wed, 23 Mar 2022 00:51:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=mimecast20200619; t=1648011101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1X05+mAXDjCO7aia+gFk+9b2MSCGquHcQYHfLT//os0=; b=Y+djZM4v9FUE9TDA/m3NKPa04DGimW3XjrLhk+G5RyBBSD4SPTDiRX402pHW/ZZYqB/m1x cAI49Litune8M7AAEo2v6Y7Z1dzqQIDtxrl6O/nzQNs9FblW2Qez7nZcIuLn2Y2tbMjtZv 1I4wt34mE5v5MytdO4X5azTTHOhatuM= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2051.outbound.protection.outlook.com [104.47.14.51]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id de-mta-2-9JLJIqW_MjKdN3WjXS0Oxw-1; Wed, 23 Mar 2022 05:51:40 +0100 X-MC-Unique: 9JLJIqW_MjKdN3WjXS0Oxw-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V8J+LXD8atPEoRu0zsJ+5iEujpDHfjtAsayOnlp+edJc8xioWcZY7bhdhs9j+7MWU2hshMTyZ/MK4W6SrJi2Jd5Ohs2DbjmoudjjLA2pBao1P0WOjAvg7VOkupNcXOhOWtPBWhnmZIbv/D9oDfsOjLowYlirYNyfF6mVQ8BjKu0VwEyFgV7l4yHmm1/aHQL8t+wYjQJLGPBF6OhODpZ2Ebt7KOUqez3rJJtRgLrqO6PIThYb5Hg6V/LnjY+sjh6IAcCNd1ENCssvcyh09hOzNzuInftYG8ndJyJG7fpld1nwc9iZLXDk/3tyIQXQ0iyYMh7/dCQtocWblXbw5ygkvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1X05+mAXDjCO7aia+gFk+9b2MSCGquHcQYHfLT//os0=; b=Ic+v2+xvivAgv2dPMdsMJVdnxcgVWPBVQkov1g5cSYp08LPsdT9Kp2LjtDb4lmudzR/DblvE0G9s+wAPKDS6NsEuTuxrN/1F0VBH6XFD8RPxaWtnzzeo0np0UTw0OAryVzhWTg3ECE6IQjimp9Zb6/9ZKMGItyJdZIPYmEdPp/yhr9UDsOVhMIQFEC5v7EnWVKH2tGa1scHMYqfEL+WkmJ682MNhKOJi20n9wP2P0Dx7D2IyKoWGd0MnoKtz4WMVTHEPcEMluTcbKUvtT2gzvv0qoSgyJD7p3qkh5Q7Ez9QIJNeDUtuYv/lfRXH5VAlmy8qB9+9VikycnegJ1PV/ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from DU2PR04MB9081.eurprd04.prod.outlook.com (2603:10a6:10:2f0::13) by PA4PR04MB7661.eurprd04.prod.outlook.com (2603:10a6:102:e3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.17; Wed, 23 Mar 2022 04:51:38 +0000 Received: from DU2PR04MB9081.eurprd04.prod.outlook.com ([fe80::2d29:445:cc37:a97f]) by DU2PR04MB9081.eurprd04.prod.outlook.com ([fe80::2d29:445:cc37:a97f%4]) with mapi id 15.20.5081.022; Wed, 23 Mar 2022 04:51:38 +0000 Date: Wed, 23 Mar 2022 12:51:32 +0800 From: Michael Chang To: The development of GNU GRUB Subject: Re: [PATCH 2/3] Fix -Werror=array-bounds array subscript 0 is outside array bounds Message-ID: <20220323045132.GA12661@mazu> References: <20220317064342.25671-1-mchang@suse.com> <20220317064342.25671-3-mchang@suse.com> <20220322211926.rresyiwsxr5csh7v@tomti.i.net-space.pl> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220322211926.rresyiwsxr5csh7v@tomti.i.net-space.pl> User-Agent: Mutt/1.10.1 (2018-07-13) X-ClientProxiedBy: HK2PR02CA0163.apcprd02.prod.outlook.com (2603:1096:201:1f::23) To DU2PR04MB9081.eurprd04.prod.outlook.com (2603:10a6:10:2f0::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5ec0944-cfac-4177-6d75-08da0c88d0ba X-MS-TrafficTypeDiagnostic: PA4PR04MB7661:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6a9IjNuStMwKgAxpui0Jdej/WvR9XSUzl6eALGfbQ5GxlT5LqmqjiL0gMESn0skLtZR6c8u6JvrbgrR/bi8PyOKgZZkqagc8UJeg0Fn49tDaCDmDDxiK85F2Fz9m0h5DfXNoWjU7hBuC4VsQb3USVokcekMYBk+aJhUn7FeiHQ0O3Vjr0+rLFIDI1PFEIh/uXt36Rv7QH9BMr/KtfI2Xs3UGSL/BCvu5LlxiEQEhtkglCkhQml6K0V7/1Mwnh+wCrCjluo5/FVlsGLKjE+tJkvG+P0YN85GuuuQvlV92KaAvCn8mA1X59+eij6W4ue7IU/R6C/wELArKw5zWndNQgeu3fC5Nwcc4BGYMoSyqHdOBJIroqjDh7txWBSOIJacNTHh1DFoYXRKoo8JzfqDtZr0cTNbemga3/MqB6YY95KtpZ3ugHgACWeF6H8oxOHsOiQysm9M59C7fsoTtpDX36X6y/fB41Jli0BL0pQ2x3eLmorYmZS6AXKH/hEwC8jkVBPQJrBPSXUDJ+L6EGaenoU1/mWK7CpRsf4qbvZK/+QXK8z4C58AqN/5ju0xyrBv1HllBh/sE/WvCptdw1VXvf5Qik2EjsP2oZlpSqoTj2TpABCxOu2lvkvgPEIuQpSyLH/C8MhLCKUARXJncIZIfbD+/7oARtMBehs8UNyXp5C7Zbgss/7ya8JvhzIJlw7nWI6jzoVnl7bu11iTtgfc9Fh8ELInw8RnoGZWYyGP5yimR1kFD5vA0XcG0k0ZflZ02 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2PR04MB9081.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(7916004)(366004)(6486002)(83380400001)(9686003)(508600001)(966005)(6512007)(66556008)(8936002)(5660300002)(6506007)(33656002)(6666004)(1076003)(186003)(38100700002)(316002)(6916009)(8676002)(2906002)(86362001)(66946007)(66476007)(33716001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?m3Lcel8RM257xJWXPMJrMJtQcB5vrOWhfrTuIWzQIDPVueygW5J5hFmcR0k5?= =?us-ascii?Q?2pwcGuobxeMYF3NAPcZ83VNdqfrX6AshIG7NTR7rMZY2jEuaGulPGu7JmsGr?= =?us-ascii?Q?LBs4oUL+bFguK6Rxw2KuLIu8U4VtUI2GcfayNDqgDwMKxm7Cx4BD0+wqxrUf?= =?us-ascii?Q?vSnH7Wo76Kkw8qkRaAmLLniTDuV9pmcaYSDrHneVq0ot4aigm9GWzakLQ5+R?= =?us-ascii?Q?CPGU9ja32V1+GgTJZ8CDhozz968sdH6/e8JaPIJFfCAgUfGLfFKB9ZG5x6YB?= =?us-ascii?Q?V71rqx/egbM6wre9/jiBc0dMe4yHLRPIJ7DGQrOsDYM0B1Uu5hAmEXGyt5lA?= =?us-ascii?Q?q7sfHiZ8A8cJ4k8CsfcLJ/zLDdZhlQuU39yJMBbLE5JZRy143G868xgx0I+L?= =?us-ascii?Q?gC0O/kZYlt7jcSNeXPQbFdUHhUShDNGVMjlQEob3zw+gr5VBW9Yq7IIKYNf0?= =?us-ascii?Q?GeNFP9kfaOfOSIOC4R2LeFapqeaFB+AWbtsN+0JGE0+6WMcaYUReuCOQkXHm?= =?us-ascii?Q?7mdEsGIGwKMATdRGWyZ5mnZpOyls64eprT6JqAUb+heuOn4IUT9BRdp5DT3r?= =?us-ascii?Q?gHLANBttZJozUqre5CWeknKgrtrSbaYOrIzMeRSxHbnD49ZDiAhGivgsYvVo?= =?us-ascii?Q?u1Q+q6noJeCt39DnNTDGyCWIDLBne9lmivBuOhl/B66lJSeAxz7hiUypXagp?= =?us-ascii?Q?UUbn5FQ1K+uppC217sgMGaSvYMdM4ug1SejzXxKXU7Ds7cUwiBXzILC2X7Cj?= =?us-ascii?Q?b/sRMtTcGL17XLFH+mfLCOwID/zi0nbCIj2Xut7iS0WE3bbSwaqQqGcgXAc0?= =?us-ascii?Q?aNsszQgx5yFSHpYBf0nPzrs4tDqhtw8y4tgoJn0RrJ4C/9da6eQ9YcTcssWA?= =?us-ascii?Q?8d8xbim3rdYCSMOuX1RJnXbeYIECQ/sFbGMj/JMouMpP5GB8CdmhJj6gFCXI?= =?us-ascii?Q?iDJI69T2xUFtcJANR2rWqA5agSBorCJaU53s1Z1l1fazzUUtzipJyFNGrR23?= =?us-ascii?Q?dzccm+BIFTwgynzG1cwL5Y3NXB1VUBpBxjscBZ4TlkNetK4yPoOKfR9iVPTl?= =?us-ascii?Q?LtKjld4IW8MB0bldBaRW//+yV5K34C9hQXPMzKKWqo6kADsS8E0Krk/d+nHM?= =?us-ascii?Q?FOhwC/ESovVPMRH33W6pY3/eb8rQXcKYJu/rC28h1YzgMAjNrnj1dwKWiOUC?= =?us-ascii?Q?kc4Rm2RJ6B0RFGwhr5nRUgNgzE2KzkvLjWxXQ059JSANx7/92/d/255Y8U5P?= =?us-ascii?Q?UEPMgWHfKsDVXzJzbe6wTiqxr1eWmPDIZ7B2tiojiSr2W2fa7AtejuBWnT8Z?= =?us-ascii?Q?UvTM3lQFxM8auYgQeUKyRT+Hts/3KeW5bwSPSW2+uW5FEsQaqz6GOcXufK8h?= =?us-ascii?Q?CBRNL3zBxkpjUQ+XGup2swUPefOgeeVoXIlAfuSoT0UIaHb7olvqOergVmpY?= =?us-ascii?Q?Yy2XvZqo3/FeHJrWUlbwdYkM/vTY1zKEjwLzbAr1J1wbMRKLwHke/8fMg49i?= =?us-ascii?Q?Qta/ny5UhnFhhWTHda+ZAyMd5hjr3geKE1OW?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5ec0944-cfac-4177-6d75-08da0c88d0ba X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB9081.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2022 04:51:38.5029 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AIjOgMs6b9zVx8CnRT5TsyKgPrYj2Mt2/QopRyk/ML2oTC1SmKZH6TZpTWzqtmd3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB7661 Received-SPF: pass client-ip=194.104.111.102; envelope-from=mchang@suse.com; helo=de-smtp-delivery-102.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2022 04:51:47 -0000 On Tue, Mar 22, 2022 at 10:19:26PM +0100, Daniel Kiper wrote: > On Thu, Mar 17, 2022 at 02:43:41PM +0800, Michael Chang via Grub-devel wrote: > > The grub is failing to build with gcc-12 in many places like this: > > > > In function 'init_cbfsdisk', > > inlined from 'grub_mod_init' at ../../grub-core/fs/cbfs.c:391:3: > > ../../grub-core/fs/cbfs.c:345:7: error: array subscript 0 is outside array bounds of 'grub_uint32_t[0]' {aka 'unsigned int[]'} [-Werror=array-bounds] > > 345 | ptr = *(grub_uint32_t *) 0xfffffffc; > > | ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > This is caused by gcc regression in 11/12 [1]. In a nut shell, the > > warning is about detected invalid accesses at non-zero offsets to null > > May I ask you to be more consistent and use NULL instead of null everywhere? Yes, no problem. > > > pointers. Since hardwired constant address is treated as NULL plus an > > offset in the same underlying code, the warning is therefore triggered. > > > > Instead of inserting #pragma all over the places where literal pointers > > are accessed to avoid diagnosing array-bounds, we can try to borrow the > > idea from linux kernel that the absolute_pointer macro [2][3] is used to > > disconnect a pointer using literal address from it's original object, > > hence gcc won't be able to make assumptions on the boundary while doing > > pointer arithmetic. With that we can greatly reduce the code we have to > > cover up by making initial literal pointer assignment to use the new > > wrapper but not having to track everywhere literal pointers are > > accessed. This also makes code looks cleaner. > > > > [1] > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > [2] > > https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180 > > [3] > > https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31 > > > > Signed-off-by: Michael Chang > > [...] > > > diff --git a/grub-core/commands/i386/pc/drivemap.c b/grub-core/commands/i386/pc/drivemap.c > > index 3fb22dc460..5e13f82eb5 100644 > > --- a/grub-core/commands/i386/pc/drivemap.c > > +++ b/grub-core/commands/i386/pc/drivemap.c > > @@ -31,9 +31,6 @@ > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > -/* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */ > > -static grub_uint32_t *const int13slot = (grub_uint32_t *) (4 * 0x13); > > - > > /* Remember to update enum opt_idxs accordingly. */ > > static const struct grub_arg_option options[] = { > > /* TRANSLATORS: In this file "mapping" refers to a change GRUB makes so if > > @@ -280,6 +277,9 @@ install_int13_handler (int noret __attribute__ ((unused))) > > grub_uint8_t *handler_base = 0; > > /* Address of the map within the deployed bundle. */ > > int13map_node_t *handler_map; > > + /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */ > > + grub_uint32_t *int13slot = (grub_uint32_t *) grub_absolute_pointer (4 * 0x13); > > This shuffling looks strange and should be explained in the commit message. > I understood what is going here when I took a look at patch #3. Yes the shuffling was due to the same reasoning provided in patch 3. I'll include it to flesh out in the commit message. > > > + > > Please drop this empty line addition. OK. > > > int i; > > int entries = 0; > > @@ -354,6 +354,9 @@ install_int13_handler (int noret __attribute__ ((unused))) > > static grub_err_t > > uninstall_int13_handler (void) > > { > > + /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */ > > + grub_uint32_t *int13slot = (grub_uint32_t *) grub_absolute_pointer (4 * 0x13); > > WRT shuffling, ditto. OK. > > > + > > if (! grub_drivemap_oldhandler) > > return GRUB_ERR_NONE; > > [...] > > > diff --git a/grub-core/term/i386/pc/console.c b/grub-core/term/i386/pc/console.c > > index d44937c305..9403390f1f 100644 > > --- a/grub-core/term/i386/pc/console.c > > +++ b/grub-core/term/i386/pc/console.c > > @@ -238,12 +238,11 @@ grub_console_getkey (struct grub_term_input *term __attribute__ ((unused))) > > return (regs.eax & 0xff) + (('a' - 1) | GRUB_TERM_CTRL); > > } > > > > -static const struct grub_machine_bios_data_area *bios_data_area = > > - (struct grub_machine_bios_data_area *) GRUB_MEMORY_MACHINE_BIOS_DATA_AREA_ADDR; > > - > > static int > > grub_console_getkeystatus (struct grub_term_input *term __attribute__ ((unused))) > > { > > + const struct grub_machine_bios_data_area *bios_data_area = > > + (struct grub_machine_bios_data_area *) grub_absolute_pointer (GRUB_MEMORY_MACHINE_BIOS_DATA_AREA_ADDR); > > Ditto and below... OK. > > > /* conveniently GRUB keystatus is modelled after BIOS one. */ > > return bios_data_area->keyboard_flag_lower & ~0x80; > > } > > [...] > > > diff --git a/include/grub/compiler.h b/include/grub/compiler.h > > index 8f3be3ae70..e159f0e292 100644 > > --- a/include/grub/compiler.h > > +++ b/include/grub/compiler.h > > @@ -56,4 +56,15 @@ > > # define CLANG_PREREQ(maj,min) 0 > > #endif > > > > +#if defined(__GNUC__) > > +# define grub_absolute_pointer(val) \ > > +({ \ > > + unsigned long __ptr; \ > > I think grub_addr_t would be more appropriate here. But this requires > include/grub/types.h. So, maybe we should move this macro there. Looks good to me. I will do in next version, > > > + __asm__ ("" : "=r"(__ptr) : "0"((void *)(val))); \ > > s/__asm__/asm/ OK. > > Why did you decide to use "asm() version" of this macro [1] instead of more > C-ish one [2]? The C-ish one doesn't work as it is acting as fallback for compilers other than gcc without the need for such hack. > Anyway, I would mention the idea comes from the Linux > kernel RELOC_HIDE() macro. I will add a comment to referencing it. Thanks a lot for review, Michael > > Daniel > > [1] https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31 > [2] https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180 > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel