Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1526238 > unrolled thread

Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-20 14:30 +0100
    Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-20 19:40 +0100
      Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-20 20:20 +0100
        Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for  ARM Nicholas Piggin <npiggin@gmail.com> - 2016-11-21 07:20 +0100

#1526238 — Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM

On Tue, Oct 25, 2016 at 07:32:00PM +1100, Nicholas Piggin wrote:
> On Mon, 24 Oct 2016 17:05:26 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > This adds an asm/asm-prototypes.h header for ARM to fix the
> > broken symbol versioning for symbols exported from assembler
> > files.
> > 
> > In addition to the header, we have to do these other small
> > changes:
> > 
> > - move the exports from bitops.h to {change,clear,set,...}bit.S
> > - move the exports from csumpartialgeneric.S into the files
> >   including it
> > 
> > I couldn't find the correct prototypes for the compiler builtins,
> > so I went with the fake 'void f(void)' prototypes that we had
> > before.
> > 
> > This leaves the mmioset/mmiocpy function for now, as it's not
> > obvious how to best handle them.
> 
> 
> This looks nicer. I like variant B because it keeps the GENKSYMS cruft to
> a single location, but either one isn't too bad.
> 
> I'd like to get moving on this, so let's at least get the generic kbuild
> change merged. In the end, the kbuild code does not prevent a maintainer
> from putting their EXPORT_SYMBOL in whatever location they like, so there
> is no reason not to merge it (certainly there will be archs that do use
> it).
> 
> 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.

Do we need to split patch 1?

Has any of these patches been committed yet?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [next] | [standalone]

#1526268

On Sun, Nov 20, 2016 at 5:21 AM, Russell King - ARM Linux
<linux@armlinux.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?

             Linus

[toc] | [prev] | [next] | [standalone]

#1526275

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@armlinux.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.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1526397 — 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@armlinux.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@armlinux.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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web