linux-kernel - Re: linux-next: build failure after merge of the origin tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210914120818.4a102b46@canb.auug.org.au>
Date:   Tue, 14 Sep 2021 12:08:18 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        PowerPC <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: linux-next: build failure after merge of the origin tree

Hi Linus,

On Mon, 13 Sep 2021 18:29:26 -0700 Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> On Mon, Sep 13, 2021 at 5:58 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > > I have no idea why it then complains about removal of the GCC4 macros.
> >
> > Me neither :-(
> 
> Ooh.
> 
> So I'm looking at gcc sources, just to see if "maybe this thing is
> somehow conditional".
> 
> And bingo.
> 
> In cpp_init_special_builtins(), gcc does
> 
>       if (b->value == BT_HAS_ATTRIBUTE
>           && (CPP_OPTION (pfile, lang) == CLK_ASM
>               || pfile->cb.has_attribute == NULL))
>         continue;
> 
> which basically says that if we're pre-processing an ASM file, the
> magical pre-processor symbol for __has_attribute is not defined.
> 
> I'm not sure what that 'pfile->cb.has_attribute == NULL' thing means,
> but the libcpp/ChangeLog file also mentions this:
> 
>         (cpp_init_special_builtins): Don't initialize __has_attribute
>         or __has_cpp_attribute if CLK_ASM or pfile->cb.has_attribute is NULL.
> 
> So this is a very very special magical thing: if building an *.S file,
> __has_attribute magically goes away.
> 
> And sure enough, that's exactly what is going on. It's during that
> build of arch/powerpc/boot/crt0.S, and the reason this hits on powerpc
> is that in arch/powerpc/boot/Makefile we have
> 
>          -include $(srctree)/include/linux/compiler_attributes.h
> 
> as part of BOOTCFLAGS, and then it does
> 
>         BOOTAFLAGS      := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
> 
> to also include that header file when building ASM files.
> 
> And our old GCC4 code silently hid this all, and made it work, because
> for a *.S file  you'd then (completely illogically) get those fake
> gcc-4 attribute macros.
> 
> Now, do I know *why* that ppc Makefile it does that? No. Neither do I
> know why the gcc people decided to just make ASM preprocessor so
> special.
> 
> But at least I understand how the odd error happens.

Its good to know there is a reason :-)

> This was too damn subtle. When you have to go read the compiler
> sources to figure things like this out, you know you are too deep.
> 
> The fix should be pretty simple: remove almost all of BOOTCFLAGS from
> BOOTAFLAGS.
> 
> But sadly, "almost all" isn't "all". There's the include path stuff,
> there's the ABI and endianness, and there's the bit size ones.
> 
> So I think the fix is either
> 
>  (a) remove that
> 
>          -include $(srctree)/include/linux/compiler_attributes.h
> 
>      thing entirely, and add it as required to the C files.
> 
> OR
> 
>  (b) something like this ENTIRELY UNTESTED ATTACHED patch
> 
> I will leave it to the powerpc people to make the right choice.

That patch works for me - for the ppc64_defconfig build at least.

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped