On Mon, 2 Dec 2024 at 21:27, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> I'm getting this in 6.13-rc1:
>
> /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:212:29: error: ptext1
> causes a section type conflict with aesgcm_tv
> static const u8 __initconst ptext1[16];
> ^~~~~~
> /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:570:9: note: ‘aesgcm_tv’ was declared here
> } const aesgcm_tv[] __initconst = {
> ^~~~~~~~~
> make[5]: *** [/home/jejb/git/linux-tpm/scripts/Makefile.build:194: lib/crypto/aesgcm.o] Error 1
> /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:212:29: error: ptext1 causes a section type conflict with aesgcm_tv
> static const u8 __initconst ptext1[16];
> ^~~~~~
> /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:570:9: note: ‘aesgcm_tv’ was declared here
> } const aesgcm_tv[] __initconst = {
> ^~~~~~~~~
> make[5]: *** [/home/jejb/git/linux-tpm/scripts/Makefile.build:194: lib/crypto/aesgcm.o] Error 1
>
> I think it's way older than 6.13-rc1, but the inclusion of the sevguest
> driver in the merge window now means that something actually selects
> it. I can fix it simply by adding a zero initialization to the file:
>
> -static const u8 __initconst ptext1[16];
> +static const u8 __initconst ptext1[16] = { 0 };
>
> Which I think means that by default the traditional zero initialization
> of a static variable is in the wrong section (and actually likely is
> wrong for all our __initX variables as well).
>
> In case it matters, this is with gcc-7
>
This also works
static const u8 __section(".init.rodata,\"a\",@progbits #") ptext1[16];
and so this suggests that without the @progbits annotations, the
compiler is placing ptext1 into a SHT_NOBITS section, causing a
conflict with the SHT_PROGBITS annotation of aesgcm_tv.
Given how unusual it is to have a static const variable without an
initializer, I don't think this suggests that there is a wider issue
with __initconst/__initdata.
We're about to bump the minimum GCC version to 8 for other reasons,
and I couldn't reproduce it with GCC 8.5.0. But the fix is
straight-forward and actually clarifies this rather odd occurrence, so
I think we should apply it nonetheless.
--
Ard.
