From: Jiri Slaby <jirislaby@kernel.org>
To: David Laight <david.laight.linux@gmail.com>,
Simon Horman <horms@kernel.org>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>,
intel-wired-lan@lists.osuosl.org,
Tony Nguyen <anthony.l.nguyen@intel.com>,
netdev@vger.kernel.org, Konrad Knitter <konrad.knitter@intel.com>,
Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <kees@kernel.org>,
Nick Desaulniers <nick.desaulniers@gmail.com>
Subject: Re: [PATCH iwl-net] ice: health.c: fix compilation on gcc 7.5
Date: Thu, 6 Feb 2025 08:53:55 +0100 [thread overview]
Message-ID: <4950e61a-189f-4749-baf7-454ca2cce250@kernel.org> (raw)
In-Reply-To: <20250205225619.31af041c@pumpkin>
On 05. 02. 25, 23:56, David Laight wrote:
> On Wed, 5 Feb 2025 20:45:46 +0000
> Simon Horman <horms@kernel.org> wrote:
>
>> + Jiri
>>
>> On Wed, Feb 05, 2025 at 11:42:12AM +0100, Przemek Kitszel wrote:
>>> GCC 7 is not as good as GCC 8+ in telling what is a compile-time const,
>>> and thus could be used for static storage. So we could not use variables
>>> for that, no matter how much "const" keyword is sprinkled around.
>>>
>>> Excerpt from the report:
>>> My GCC is: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
>>>
>>> CC [M] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o
>>> drivers/net/ethernet/intel/ice/devlink/health.c:35:3: error: initializer element is not constant
>>> ice_common_port_solutions, {ice_port_number_label}},
>>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>>> drivers/net/ethernet/intel/ice/devlink/health.c:35:3: note: (near initialization for 'ice_health_status_lookup[0].solution')
>>> drivers/net/ethernet/intel/ice/devlink/health.c:35:31: error: initializer element is not constant
>>> ice_common_port_solutions, {ice_port_number_label}},
>>> ^~~~~~~~~~~~~~~~~~~~~
>>> drivers/net/ethernet/intel/ice/devlink/health.c:35:31: note: (near initialization for 'ice_health_status_lookup[0].data_label[0]')
>>> drivers/net/ethernet/intel/ice/devlink/health.c:37:46: error: initializer element is not constant
>>> "Change or replace the module or cable.", {ice_port_number_label}},
>>> ^~~~~~~~~~~~~~~~~~~~~
>>> drivers/net/ethernet/intel/ice/devlink/health.c:37:46: note: (near initialization for 'ice_health_status_lookup[1].data_label[0]')
>>> drivers/net/ethernet/intel/ice/devlink/health.c:39:3: error: initializer element is not constant
>>> ice_common_port_solutions, {ice_port_number_label}},
>>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Fixes: 85d6164ec56d ("ice: add fw and port health reporters")
>>> Reported-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
>>> Closes: https://lore.kernel.org/netdev/CY8PR11MB7134BF7A46D71E50D25FA7A989F72@CY8PR11MB7134.namprd11.prod.outlook.com
>>> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>>> ---
>>> I would really like to bump min gcc to 8.5 (RH 8 family),
>>> instead of supporting old Ubuntu. However SLES 15 is also stuck with gcc 7.5 :(
>>>
>>> CC: Linus Torvalds <torvalds@linux-foundation.org>
>>> CC: Kees Cook <kees@kernel.org>
>>> CC: Nick Desaulniers <nick.desaulniers@gmail.com>
>>
>> Hi Prezemek,
>>
>> I ran into a similar problem not so long ago and I'm wondering if
>> the following, based on a suggestion by Jiri Slaby, resolves your
>> problem.
>
> I'm sure I remember from somewhere that although the variables are
> 'static const' they have to be real variables because they can still
> be patched.
Not sure what you mean -- using macros, they placed the strings into
.rodata anyway.
Mind the difference between:
const char *X;
char *const X;
const char *const X;
They are all different and allow different things (X++, (*X)++, nothing).
Possibly, the problem above could be fixed by the third variant too,
IMO. But is ineffective (having generated an unused pointer).
thanks,
--
js
suse labs
next prev parent reply other threads:[~2025-02-06 7:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 10:42 [PATCH iwl-net] ice: health.c: fix compilation on gcc 7.5 Przemek Kitszel
2025-02-05 11:19 ` Michal Swiatkowski
2025-02-05 11:39 ` Zhuo, Qiuxu
2025-02-05 20:45 ` Simon Horman
2025-02-05 22:56 ` David Laight
2025-02-06 7:53 ` Jiri Slaby [this message]
2025-02-06 7:45 ` Jiri Slaby
2025-02-06 18:57 ` Kees Cook
2025-03-14 7:03 ` [Intel-wired-lan] " Mekala, SunithaX D
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4950e61a-189f-4749-baf7-454ca2cce250@kernel.org \
--to=jirislaby@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=david.laight.linux@gmail.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kees@kernel.org \
--cc=konrad.knitter@intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=nick.desaulniers@gmail.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=qiuxu.zhuo@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).