On Mon, Sep 6, 2021 at 4:36 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > --- a/drivers/pinctrl/renesas/core.c
> > +++ b/drivers/pinctrl/renesas/core.c
> > @@ -741,12 +741,12 @@ static int sh_pfc_suspend_init(struct sh_pfc *pfc) { return 0; }
> > #define SH_PFC_MAX_REGS 300
> > #define SH_PFC_MAX_ENUMS 3000
> >
> > -static unsigned int sh_pfc_errors __initdata = 0;
> > -static unsigned int sh_pfc_warnings __initdata = 0;
> > -static u32 *sh_pfc_regs __initdata = NULL;
> > -static u32 sh_pfc_num_regs __initdata = 0;
> > -static u16 *sh_pfc_enums __initdata = NULL;
> > -static u32 sh_pfc_num_enums __initdata = 0;
> > +static unsigned int sh_pfc_errors __initdata;
> > +static unsigned int sh_pfc_warnings __initdata;
> > +static u32 *sh_pfc_regs __initdata;
> > +static u32 sh_pfc_num_regs __initdata;
> > +static u16 *sh_pfc_enums __initdata;
> > +static u32 sh_pfc_num_enums __initdata;
>
> These are special, as they use __initdata.
> While dropping the initializers seems to work fine with e.g. gcc 9,
> I'm quite sure that would fail with older compiler versions, where
> the variable would be put in bss instead of initdata.
>
> See the example in include/linux/init.h, which explicitly
> initializes a variable with zero:
>
> static int init_variable __initdata = 0;
>
> Arnd: do you know in which version of gcc this was fixed?
> It seems at least 6.5.0 and later are fine (I don't have all required
> shared libs to run e.g. 5.5.0).
I think you mixed up what happens: As far as I know, older compilers
would put variables without the =0 into .bss, but those with the explicit
=0 would end up in .data. Newer compilers treat them exactly the
same, and these variables all get put into .bss by default. This seems
to already be the case with gcc-4.1, which is the oldest one I could
easily try.
I'm rather sure that regardless of the compiler version, adding an
explicit section attribute like the __initdata would force the section
even on the pre-4.1 compilers.
Arnd
