[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161121171057.3ae027a6@roar.ozlabs.ibm.com>
Date: Mon, 21 Nov 2016 17:10:57 +1100
From: Nicholas Piggin <npiggin@...il.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, Michal Marek <mmarek@...e.com>,
Adam Borowski <kilobyte@...band.pl>,
Omar Sandoval <osandov@...ndov.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Al Viro <viro@...iv.linux.org.uk>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for
ARM
On Sun, 20 Nov 2016 19:12:57 +0000
Russell King - ARM Linux <linux@...linux.org.uk> 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@...linux.org.uk> 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
>
> .endm
>
> 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.
http://marc.info/?l=linux-kbuild&m=147732160529499&w=2
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.
Thanks,
Nick
Powered by blists - more mailing lists