Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicholas Piggin
Date: Mon Nov 21 2016 - 01:11:22 EST
On Sun, 20 Nov 2016 19:12:57 +0000
Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> wrote:
> On Sun, Nov 20, 2016 at 10:32:50AM -0800, Linus Torvalds wrote:
> > On Sun, Nov 20, 2016 at 5:21 AM, Russell King - ARM Linux
> > <linux@xxxxxxxxxxxxxxx> wrote:
> > > On Tue, Oct 25, 2016 at 07:32:00PM +1100, Nicholas Piggin wrote:
> > >>
> > >> Michal, what's your thoughts? If you merge my patch 2/2 and skip 1/2, it
> > >> should not give any new build warnings or errors, so then arch patches can
> > >> go via arch trees. 1/2 could go in after everyone is up to date.
> > >
> > > So what's the conclusion on this? I've just had a failure due to
> > > CONFIG_TRIM_UNUSED_KSYMS reported on ARM, and it looks like (at
> > > least some of) patch 1 could resolve it.
> > Hmm. I've got
> > cc6acc11cad1 kbuild: be more careful about matching preprocessed asm
> > ___EXPORT_SYMBOL
> > 4efca4ed05cb kbuild: modversions for EXPORT_SYMBOL() for asm
> > in my tree. Is that sufficient, or do we still have issues?
> Hmm, those seem to have gone in during the last week, so I haven't
> tested it yet (build running, but it'll take a while). However, I
> don't think they'll solve _this_ problem.
> Some of the issue here is that we use a mixture of assembly macros
> and preprocessor for the ARM bitops - the ARM bitops are created
> with an assembly macro which contains some pre-processor expanded
> macros (eg, EXPORT_SYMBOL()).
> This means that the actual symbol being exported is not known to
> the preprocessor, so doing the "__is_defined(__KSYM_##sym)" inside
> "EXPORT_SYMBOL(\name)" becomes "__is_defined(__KSYM_\name)" to the
> preprocessor. As "__KSYM_\name" is never defined, it always comes
> out as zero, hence we always use __cond_export_sym_0, which omits
> the symbol export from the assembly macro definition:
> .macro bitop, name, instr
> .globl \name ; .align 0 ; \name:
> .type \name, %function; .size \name, .-\name
> In other words, using preprocessor macros inside an assembly macro
> may not work as expected, and now leads to config-specific failures.
Yes, that's a limitation. cpp expansion we can handle, but not gas macros.
You will need Arnd's patches for ARM.
If that doesn't fix it for you, send me your .config offline and I'll set
up a cross compile to work on it.
Again, any arch always has the option of going back to doing asm exports
in the old style of putting them into a .c file, but hopefully you'll find
Arnd's reworked patches to be something you're willing to merge.