[PATCH 0/2] initramfs: Cleanup and fix initramfs size calculation

[PATCH 0/2] initramfs: Cleanup and fix initramfs size calculation

[Hendrik Brueckner]

Hello Michal, Sam,

I did not see any further comments on the patch series about the
initramfs cleanup and new size calculation.

This is a resend and now I am asking you for your review and ack.
Please let me know if you have questions or comments.

Thanks and kind regards,
Hendrik

[PATCH 1/2] initramfs: Generalize initramfs_data.xxx.S variants

[Hendrik Brueckner]

[-- Attachment #1: irfs1.patch --]
[-- Type: text/plain, Size: 6309 bytes --]

Remove initramfs_data.{lzo,lzma,gz,bz2}.S variants and use a common
implementation in initramfs_data.S.  The common implementation expects
the file name of the initramfs to be defined in INITRAMFS_IMAGE.

Change the Makefile to set the INITRAMFS_IMAGE define symbol according
to the selected compression method.

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
---
 usr/Makefile              |    6 ++++--
 usr/initramfs_data.S      |    5 +++--
 usr/initramfs_data.bz2.S  |   29 -----------------------------
 usr/initramfs_data.gz.S   |   29 -----------------------------
 usr/initramfs_data.lzma.S |   29 -----------------------------
 usr/initramfs_data.lzo.S  |   29 -----------------------------
 6 files changed, 7 insertions(+), 120 deletions(-)

--- a/usr/Makefile
+++ b/usr/Makefile
@@ -18,13 +18,15 @@ suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZ
 # Lzo
 suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZO)   = .lzo
 
+AFLAGS_initramfs_data.o += -DINITRAMFS_IMAGE="usr/initramfs_data.cpio$(suffix_y)"
+
 # Generate builtin.o based on initramfs_data.o
-obj-$(CONFIG_BLK_DEV_INITRD) := initramfs_data$(suffix_y).o
+obj-$(CONFIG_BLK_DEV_INITRD) := initramfs_data.o
 
 # initramfs_data.o contains the compressed initramfs_data.cpio image.
 # The image is included using .incbin, a dependency which is not
 # tracked automatically.
-$(obj)/initramfs_data$(suffix_y).o: $(obj)/initramfs_data.cpio$(suffix_y) FORCE
+$(obj)/initramfs_data.o: $(obj)/initramfs_data.cpio$(suffix_y) FORCE
 
 #####
 # Generate the initramfs cpio archive
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -25,6 +25,7 @@ SECTIONS
   in the ELF header, as required by certain architectures.
 */
 
-.section .init.ramfs,"a"
-.incbin "usr/initramfs_data.cpio"
+#include <linux/stringify.h>
 
+.section .init.ramfs,"a"
+.incbin __stringify(INITRAMFS_IMAGE)
--- a/usr/initramfs_data.bz2.S
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
-  initramfs_data includes the compressed binary that is the
-  filesystem used for early user space.
-  Note: Older versions of "as" (prior to binutils 2.11.90.0.23
-  released on 2001-07-14) dit not support .incbin.
-  If you are forced to use older binutils than that then the
-  following trick can be applied to create the resulting binary:
-
-
-  ld -m elf_i386  --format binary --oformat elf32-i386 -r \
-  -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
-   ld -m elf_i386  -r -o built-in.o initramfs_data.o
-
-  initramfs_data.scr looks like this:
-SECTIONS
-{
-       .init.ramfs : { *(.data) }
-}
-
-  The above example is for i386 - the parameters vary from architectures.
-  Eventually look up LDFLAGS_BLOB in an older version of the
-  arch/$(ARCH)/Makefile to see the flags used before .incbin was introduced.
-
-  Using .incbin has the advantage over ld that the correct flags are set
-  in the ELF header, as required by certain architectures.
-*/
-
-.section .init.ramfs,"a"
-.incbin "usr/initramfs_data.cpio.bz2"
--- a/usr/initramfs_data.gz.S
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
-  initramfs_data includes the compressed binary that is the
-  filesystem used for early user space.
-  Note: Older versions of "as" (prior to binutils 2.11.90.0.23
-  released on 2001-07-14) dit not support .incbin.
-  If you are forced to use older binutils than that then the
-  following trick can be applied to create the resulting binary:
-
-
-  ld -m elf_i386  --format binary --oformat elf32-i386 -r \
-  -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
-   ld -m elf_i386  -r -o built-in.o initramfs_data.o
-
-  initramfs_data.scr looks like this:
-SECTIONS
-{
-       .init.ramfs : { *(.data) }
-}
-
-  The above example is for i386 - the parameters vary from architectures.
-  Eventually look up LDFLAGS_BLOB in an older version of the
-  arch/$(ARCH)/Makefile to see the flags used before .incbin was introduced.
-
-  Using .incbin has the advantage over ld that the correct flags are set
-  in the ELF header, as required by certain architectures.
-*/
-
-.section .init.ramfs,"a"
-.incbin "usr/initramfs_data.cpio.gz"
--- a/usr/initramfs_data.lzma.S
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
-  initramfs_data includes the compressed binary that is the
-  filesystem used for early user space.
-  Note: Older versions of "as" (prior to binutils 2.11.90.0.23
-  released on 2001-07-14) dit not support .incbin.
-  If you are forced to use older binutils than that then the
-  following trick can be applied to create the resulting binary:
-
-
-  ld -m elf_i386  --format binary --oformat elf32-i386 -r \
-  -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
-   ld -m elf_i386  -r -o built-in.o initramfs_data.o
-
-  initramfs_data.scr looks like this:
-SECTIONS
-{
-       .init.ramfs : { *(.data) }
-}
-
-  The above example is for i386 - the parameters vary from architectures.
-  Eventually look up LDFLAGS_BLOB in an older version of the
-  arch/$(ARCH)/Makefile to see the flags used before .incbin was introduced.
-
-  Using .incbin has the advantage over ld that the correct flags are set
-  in the ELF header, as required by certain architectures.
-*/
-
-.section .init.ramfs,"a"
-.incbin "usr/initramfs_data.cpio.lzma"
--- a/usr/initramfs_data.lzo.S
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
-  initramfs_data includes the compressed binary that is the
-  filesystem used for early user space.
-  Note: Older versions of "as" (prior to binutils 2.11.90.0.23
-  released on 2001-07-14) dit not support .incbin.
-  If you are forced to use older binutils than that then the
-  following trick can be applied to create the resulting binary:
-
-
-  ld -m elf_i386  --format binary --oformat elf32-i386 -r \
-  -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
-   ld -m elf_i386  -r -o built-in.o initramfs_data.o
-
-  initramfs_data.scr looks like this:
-SECTIONS
-{
-       .init.ramfs : { *(.data) }
-}
-
-  The above example is for i386 - the parameters vary from architectures.
-  Eventually look up LDFLAGS_BLOB in an older version of the
-  arch/$(ARCH)/Makefile to see the flags used before .incbin was introduced.
-
-  Using .incbin has the advantage over ld that the correct flags are set
-  in the ELF header, as required by certain architectures.
-*/
-
-.section .init.ramfs,"a"
-.incbin "usr/initramfs_data.cpio.lzo"

-- 

[PATCH 2/2] initramfs: Fix initramfs size calculation

[Hendrik Brueckner]

[-- Attachment #1: irfs2.patch --]
[-- Type: text/plain, Size: 4531 bytes --]

The size of a built-in initramfs is calculated in init/initramfs.c by 
"__initramfs_end - __initramfs_start".  Those symbols are defined in the
linker script include/asm-generic/vmlinux.lds.h:

#define INIT_RAM_FS                                                     \
        . = ALIGN(PAGE_SIZE);                                           \
        VMLINUX_SYMBOL(__initramfs_start) = .;                          \
        *(.init.ramfs)                                                  \
        VMLINUX_SYMBOL(__initramfs_end) = .;

If the initramfs file has an odd number of bytes, the "__initramfs_end"
symbol points to an odd address, for example, the symbols in the System.map
might look like:

    0000000000572000 T __initramfs_start
    00000000005bcd05 T __initramfs_end	  <-- odd address

At least on s390 this causes a problem:

Certain s390 instructions, especially instructions for loading addresses
(larl) or branch addresses must be on even addresses. 
The compiler loads the symbol addresses with the "larl" instruction. This
instruction sets the last bit to 0 and, therefore, for odd size files, the
calculated size is one byte less than it should be:

    0000000000540a9c <populate_rootfs>:
      540a9c:     eb cf f0 78 00 24       stmg    %r12,%r15,120(%r15),
      540aa2:     c0 10 00 01 8a af       larl    %r1,572000 <__initramfs_start>
      540aa8:     c0 c0 00 03 e1 2e       larl    %r12,5bcd04 <initramfs_end>
                                                  (Instead of  5bcd05)
      ...
      540abe:     1b c1                   sr      %r12,%r1

To fix the problem, this patch introduces the global variable
__initramfs_size, which is calculated in the "usr/initramfs_data.S" file.
The populate_rootfs() function can then use the start marker of the
.init.ramfs section and the value of __initramfs_size for loading the
initramfs.  Because the start marker and size is sufficient, the
__initramfs_end symbol is no longer needed and is removed.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
---
 include/asm-generic/vmlinux.lds.h |    3 ++-
 init/initramfs.c                  |    9 ++++-----
 usr/initramfs_data.S              |   16 +++++++++++-----
 3 files changed, 17 insertions(+), 11 deletions(-)

--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -629,7 +629,8 @@
 	. = ALIGN(PAGE_SIZE);						\
 	VMLINUX_SYMBOL(__initramfs_start) = .;				\
 	*(.init.ramfs)							\
-	VMLINUX_SYMBOL(__initramfs_end) = .;
+	. = ALIGN(8);							\
+	*(.init.ramfs.info)
 #else
 #define INIT_RAM_FS
 #endif
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -483,7 +483,8 @@ static int __init retain_initrd_param(ch
 }
 __setup("retain_initrd", retain_initrd_param);
 
-extern char __initramfs_start[], __initramfs_end[];
+extern char __initramfs_start[];
+extern unsigned long __initramfs_size;
 #include <linux/initrd.h>
 #include <linux/kexec.h>
 
@@ -570,8 +571,7 @@ static void __init clean_rootfs(void)
 
 static int __init populate_rootfs(void)
 {
-	char *err = unpack_to_rootfs(__initramfs_start,
-			 __initramfs_end - __initramfs_start);
+	char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
 	if (err)
 		panic(err);	/* Failed to decompress INTERNAL initramfs */
 	if (initrd_start) {
@@ -585,8 +585,7 @@ static int __init populate_rootfs(void)
 			return 0;
 		} else {
 			clean_rootfs();
-			unpack_to_rootfs(__initramfs_start,
-				 __initramfs_end - __initramfs_start);
+			unpack_to_rootfs(__initramfs_start, __initramfs_size);
 		}
 		printk(KERN_INFO "rootfs image is not initramfs (%s)"
 				"; looks like an initrd\n", err);
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -11,11 +11,7 @@
   -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
    ld -m elf_i386  -r -o built-in.o initramfs_data.o
 
-  initramfs_data.scr looks like this:
-SECTIONS
-{
-       .init.ramfs : { *(.data) }
-}
+  For including the .init.ramfs sections, see include/asm-generic/vmlinux.lds.
 
   The above example is for i386 - the parameters vary from architectures.
   Eventually look up LDFLAGS_BLOB in an older version of the
@@ -28,4 +24,14 @@ SECTIONS
 #include <linux/stringify.h>
 
 .section .init.ramfs,"a"
+__irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)
+__irf_end:
+.section .init.ramfs.info,"a"
+.globl __initramfs_size
+__initramfs_size:
+#ifdef CONFIG_32BIT
+	.long __irf_end - __irf_start
+#else
+	.quad __irf_end - __irf_start
+#endif

-- 

Re: [PATCH 2/2] initramfs: Fix initramfs size calculation

[Américo Wang]

On Tue, Aug 31, 2010 at 10:23:09AM +0200, Hendrik Brueckner wrote:
>The size of a built-in initramfs is calculated in init/initramfs.c by 
>"__initramfs_end - __initramfs_start".  Those symbols are defined in the
>linker script include/asm-generic/vmlinux.lds.h:
>
>#define INIT_RAM_FS                                                     \
>        . = ALIGN(PAGE_SIZE);                                           \
>        VMLINUX_SYMBOL(__initramfs_start) = .;                          \
>        *(.init.ramfs)                                                  \
>        VMLINUX_SYMBOL(__initramfs_end) = .;
>
>If the initramfs file has an odd number of bytes, the "__initramfs_end"
>symbol points to an odd address, for example, the symbols in the System.map
>might look like:
>
>    0000000000572000 T __initramfs_start
>    00000000005bcd05 T __initramfs_end	  <-- odd address
>
>At least on s390 this causes a problem:
>
>Certain s390 instructions, especially instructions for loading addresses
>(larl) or branch addresses must be on even addresses. 
>The compiler loads the symbol addresses with the "larl" instruction. This
>instruction sets the last bit to 0 and, therefore, for odd size files, the
>calculated size is one byte less than it should be:
>
>    0000000000540a9c <populate_rootfs>:
>      540a9c:     eb cf f0 78 00 24       stmg    %r12,%r15,120(%r15),
>      540aa2:     c0 10 00 01 8a af       larl    %r1,572000 <__initramfs_start>
>      540aa8:     c0 c0 00 03 e1 2e       larl    %r12,5bcd04 <initramfs_end>
>                                                  (Instead of  5bcd05)
>      ...
>      540abe:     1b c1                   sr      %r12,%r1
>
>To fix the problem, this patch introduces the global variable
>__initramfs_size, which is calculated in the "usr/initramfs_data.S" file.
>The populate_rootfs() function can then use the start marker of the
>.init.ramfs section and the value of __initramfs_size for loading the
>initramfs.  Because the start marker and size is sufficient, the
>__initramfs_end symbol is no longer needed and is removed.
>
>Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>


This patch looks good for me too,

Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>

I think Michal will take this into kbuild tree.

Thanks!

Re: [PATCH 2/2] initramfs: Fix initramfs size calculation

[Mike Frysinger]

On Tue, Aug 31, 2010 at 04:23, Hendrik Brueckner wrote:
> --- a/usr/initramfs_data.S
> +++ b/usr/initramfs_data.S
> @@ -28,4 +24,14 @@ SECTIONS
>  #include <linux/stringify.h>
>
>  .section .init.ramfs,"a"
> +__irf_start:
>  .incbin __stringify(INITRAMFS_IMAGE)
> +__irf_end:
> +.section .init.ramfs.info,"a"
> +.globl __initramfs_size
> +__initramfs_size:
> +#ifdef CONFIG_32BIT
> +       .long __irf_end - __irf_start
> +#else
> +       .quad __irf_end - __irf_start
> +#endif

i'm pretty sure this breaks on every symbol-prefixed arch.  at least,
it broke every Blackfin board:
init/built-in.o: In function `populate_rootfs':
init/initramfs.c:(.init.text+0x2548): undefined reference to `__initramfs_size'
init/initramfs.c:(.init.text+0x254e): undefined reference to `__initramfs_size'
make: *** [.tmp_vmlinux1] Error 1

look at VMLINUX_SYMBOL() in the vmlinux.lds.h file
-mike

Re: [PATCH 2/2] initramfs: Fix initramfs size calculation

[Hendrik Brueckner]

Hi Mike,

On Sun, Oct 17, 2010 at 02:28:11PM -0400, Mike Frysinger wrote:
> On Tue, Aug 31, 2010 at 04:23, Hendrik Brueckner wrote:
> i'm pretty sure this breaks on every symbol-prefixed arch.  at least,
> it broke every Blackfin board:
> init/built-in.o: In function `populate_rootfs':
> init/initramfs.c:(.init.text+0x2548): undefined reference to `__initramfs_size'
> init/initramfs.c:(.init.text+0x254e): undefined reference to `__initramfs_size'
> make: *** [.tmp_vmlinux1] Error 1
> 
> look at VMLINUX_SYMBOL() in the vmlinux.lds.h file

Thanks for your feedback.  Could you try the patch below and let me know
if it works for your Blackfin board.

Thanks and kind regards,
  Hendrik

--- 8< ----------------

Define the __initramfs_size variable using VMLINUX_SYMBOL() to take
care of symbol-prefixed architectures, for example, blackfin.

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
---
 usr/initramfs_data.S |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -22,14 +22,15 @@
 */
 
 #include <linux/stringify.h>
+#include <asm-generic/vmlinux.lds.h>
 
 .section .init.ramfs,"a"
 __irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)
 __irf_end:
 .section .init.ramfs.info,"a"
-.globl __initramfs_size
-__initramfs_size:
+.globl VMLINUX_SYMBOL(__initramfs_size)
+VMLINUX_SYMBOL(__initramfs_size):
 #ifdef CONFIG_32BIT
 	.long __irf_end - __irf_start
 #else

Re: [PATCH 2/2] initramfs: Fix initramfs size calculation

[Mike Frysinger]

On Mon, Oct 18, 2010 at 06:37, Hendrik Brueckner wrote:
> On Sun, Oct 17, 2010 at 02:28:11PM -0400, Mike Frysinger wrote:
>> On Tue, Aug 31, 2010 at 04:23, Hendrik Brueckner wrote:
>> i'm pretty sure this breaks on every symbol-prefixed arch.  at least,
>> it broke every Blackfin board:
>> init/built-in.o: In function `populate_rootfs':
>> init/initramfs.c:(.init.text+0x2548): undefined reference to `__initramfs_size'
>> init/initramfs.c:(.init.text+0x254e): undefined reference to `__initramfs_size'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> look at VMLINUX_SYMBOL() in the vmlinux.lds.h file
>
> Thanks for your feedback.  Could you try the patch below and let me know
> if it works for your Blackfin board.

negative.  same error.  vmlinux.lds.h might need to be switched to
CONFIG_SYMBOL_PREFIX.
-mike

[PATCH] initramfs: Fix build break on symbol-prefixed archs

[Hendrik Brueckner]

Hi Mike,

On Mon, Oct 18, 2010 at 07:07:13PM -0400, Mike Frysinger wrote:
> On Mon, Oct 18, 2010 at 06:37, Hendrik Brueckner wrote:
> > On Sun, Oct 17, 2010 at 02:28:11PM -0400, Mike Frysinger wrote:
> >> On Tue, Aug 31, 2010 at 04:23, Hendrik Brueckner wrote:
> >> i'm pretty sure this breaks on every symbol-prefixed arch.  at least,
> >> it broke every Blackfin board:
> >> init/built-in.o: In function `populate_rootfs':
> >> init/initramfs.c:(.init.text+0x2548): undefined reference to `__initramfs_size'
> >> init/initramfs.c:(.init.text+0x254e): undefined reference to `__initramfs_size'
> >> make: *** [.tmp_vmlinux1] Error 1
> >>
> negative.  same error.  vmlinux.lds.h might need to be switched to
> CONFIG_SYMBOL_PREFIX.

In my previous patch I missed a change regarding the SYMBOL_PREFIX symbol.
The SYMBOL_PREFIX symbol, which is used by VMLINUX_SYMBOL, is derived
from the CONFIG_SYMBOL_PREFIX and must be defined in the Makefile.

Below you can find the updated patch which worked for my blackfin test build.

Thanks and kind regards,
  Hendrik

--- 8< -----------------------
Define the __initramfs_size variable using VMLINUX_SYMBOL() to take
care of symbol-prefixed architectures, for example, blackfin.

Depending on the CONFIG_SYMBOL_PREFIX configuration option, define
the SYMBOL_PREFIX symbol which is evaluated by VMLINUX_SYMBOL().

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
---
 usr/Makefile         |    3 +++
 usr/initramfs_data.S |    5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)

--- a/usr/Makefile
+++ b/usr/Makefile
@@ -19,6 +19,9 @@ suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZ
 suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZO)   = .lzo
 
 AFLAGS_initramfs_data.o += -DINITRAMFS_IMAGE="usr/initramfs_data.cpio$(suffix_y)"
+ifdef CONFIG_SYMBOL_PREFIX
+AFLAGS_initramfs_data.o += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
+endif
 
 # Generate builtin.o based on initramfs_data.o
 obj-$(CONFIG_BLK_DEV_INITRD) := initramfs_data.o
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -22,14 +22,15 @@
 */
 
 #include <linux/stringify.h>
+#include <asm-generic/vmlinux.lds.h>
 
 .section .init.ramfs,"a"
 __irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)
 __irf_end:
 .section .init.ramfs.info,"a"
-.globl __initramfs_size
-__initramfs_size:
+.globl VMLINUX_SYMBOL(__initramfs_size)
+VMLINUX_SYMBOL(__initramfs_size):
 #ifdef CONFIG_32BIT
 	.long __irf_end - __irf_start
 #else

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Tue, Oct 19, 2010 at 07:08, Hendrik Brueckner wrote:
> --- a/usr/Makefile
> +++ b/usr/Makefile
> @@ -19,6 +19,9 @@ suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZ
>  suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZO)   = .lzo
>
>  AFLAGS_initramfs_data.o += -DINITRAMFS_IMAGE="usr/initramfs_data.cpio$(suffix_y)"
> +ifdef CONFIG_SYMBOL_PREFIX
> +AFLAGS_initramfs_data.o += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
> +endif
>
>  # Generate builtin.o based on initramfs_data.o
>  obj-$(CONFIG_BLK_DEV_INITRD) := initramfs_data.o

i dont think we want to go this route.  keep it in one place:
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -120,7 +120,9 @@ _c_flags += $(if $(patsubst n%,, \
 endif

 ifdef CONFIG_SYMBOL_PREFIX
-_cpp_flags += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
+_sym_flags = -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
+_cpp_flags += $(_sym_flags)
+_a_flags += $(_sym_flags)
 endif


-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Sam Ravnborg]

On Tue, Oct 19, 2010 at 04:11:53PM -0400, Mike Frysinger wrote:
> On Tue, Oct 19, 2010 at 07:08, Hendrik Brueckner wrote:
> > --- a/usr/Makefile
> > +++ b/usr/Makefile
> > @@ -19,6 +19,9 @@ suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZ
> >  suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZO)   = .lzo
> >
> >  AFLAGS_initramfs_data.o += -DINITRAMFS_IMAGE="usr/initramfs_data.cpio$(suffix_y)"
> > +ifdef CONFIG_SYMBOL_PREFIX
> > +AFLAGS_initramfs_data.o += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
> > +endif
> >
> >  # Generate builtin.o based on initramfs_data.o
> >  obj-$(CONFIG_BLK_DEV_INITRD) := initramfs_data.o
> 
> i dont think we want to go this route.  keep it in one place:
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -120,7 +120,9 @@ _c_flags += $(if $(patsubst n%,, \
>  endif
> 
>  ifdef CONFIG_SYMBOL_PREFIX
> -_cpp_flags += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
> +_sym_flags = -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
> +_cpp_flags += $(_sym_flags)
> +_a_flags += $(_sym_flags)
>  endif

The right fix would be to fix some unfortunate breakage in kbuild.
The value of _cpp_flags is only used for preprocessing linker scripts,
but should be used for as and gcc too.

A small analysis:
Today we have different ways to set preprocessor flags.

KBUILD_CPPFLAGS - set in top-level Makefile + arch MAkefile
                  used by all of cpp, as, gcc

EXTRA_CPPFLAGS  - not used at all and can be deleted

cppflags-y      - set in Kbuild files
                - only used when preprocessing linker scripts

CPPFLAGS_<target> - used for linker scripts in many places

It looks like the following untested patch should fix it.
With this patch we have SYMBOL_PREFIX defined when
building assembler files too.

The patch fix it so flags used for preprocessing is also applied
to as and gcc.

@Michal - do you follow my rationale and do you agree?


Another way to fix this would be to fix asm-generic/vmlinx.lds.h
to check for CONFIG_SYMBOL_PREFIX direct.
I cannot see why we require the SYMBOL_PREFIX definition.

See patch number two below for my take on it.
This is my preferred way to deal with this.
The cppflags fix can wait a little.

	Sam

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 54fd1b7..1b8f15d 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -109,10 +109,10 @@ else
 debug_flags =
 endif
 
-orig_c_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \
+orig_c_flags   = $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \
                  $(ccflags-y) $(CFLAGS_$(basetarget).o)
 _c_flags       = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags))
-_a_flags       = $(KBUILD_CPPFLAGS) $(KBUILD_AFLAGS) $(KBUILD_SUBDIR_ASFLAGS) \
+_a_flags       = $(KBUILD_AFLAGS) $(KBUILD_SUBDIR_ASFLAGS) \
                  $(asflags-y) $(AFLAGS_$(basetarget).o)
 _cpp_flags     = $(KBUILD_CPPFLAGS) $(cppflags-y) $(CPPFLAGS_$(@F))
 
@@ -150,16 +150,14 @@ __a_flags	=                          $(call flags,_a_flags)
 __cpp_flags     =                          $(call flags,_cpp_flags)
 endif
 
-c_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \
-		 $(__c_flags) $(modkern_cflags)                           \
+cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \
+		 $(__cpp_flags)
+
+c_flags        = $(cpp_flags) $(__c_flags) $(modkern_cflags)              \
 		 -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) \
 		  $(debug_flags)
 
-a_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \
-		 $(__a_flags) $(modkern_aflags)
-
-cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \
-		 $(__cpp_flags)
+a_flags        = $(cpp_flags) $(__a_flags) $(modkern_aflags)
 
 ld_flags       = $(LDFLAGS) $(ldflags-y)
 





diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 8a92a17..520e4ac 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -52,12 +52,12 @@
 #define LOAD_OFFSET 0
 #endif
 
-#ifndef SYMBOL_PREFIX
+#ifndef CONFIG_SYMBOL_PREFIX
 #define VMLINUX_SYMBOL(sym) sym
 #else
 #define PASTE2(x,y) x##y
 #define PASTE(x,y) PASTE2(x,y)
-#define VMLINUX_SYMBOL(sym) PASTE(SYMBOL_PREFIX, sym)
+#define VMLINUX_SYMBOL(sym) PASTE(CONFIG_SYMBOL_PREFIX, sym)
 #endif
 
 /* Align . to a 8 byte boundary equals to maximum function alignment. */
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 54fd1b7..08e13b1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -127,10 +127,6 @@ _c_flags += $(if $(patsubst n%,, \
 		$(CFLAGS_GCOV))
 endif
 
-ifdef CONFIG_SYMBOL_PREFIX
-_cpp_flags += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
-endif
-
 
 # If building the kernel in a separate objtree expand all occurrences
 # of -Idir to -I$(srctree)/dir except for absolute paths (starting with '/').

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Tue, Oct 19, 2010 at 17:31, Sam Ravnborg wrote:
> Another way to fix this would be to fix asm-generic/vmlinx.lds.h
> to check for CONFIG_SYMBOL_PREFIX direct.
> I cannot see why we require the SYMBOL_PREFIX definition.

because CONFIG_SYMBOL_PREFIX is "_" when we need it to be _ and the
cpp has no way of removing quotes
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

can we get this change dropped from linux-next until someone gets a
chance to fix it ?
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Michal Marek]

On 27.10.2010 20:23, Mike Frysinger wrote:
> can we get this change dropped from linux-next until someone gets a
> chance to fix it ?

Sorry I missed this thread. So your last patch
(http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
failure? Can you submit it with a proper Signed-off-by and changelog?

Thanks a lot,
Michal

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Wed, Oct 27, 2010 at 18:46, Michal Marek wrote:
> On 27.10.2010 20:23, Mike Frysinger wrote:
>> can we get this change dropped from linux-next until someone gets a
>> chance to fix it ?
>
> Sorry I missed this thread. So your last patch
> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
> failure? Can you submit it with a proper Signed-off-by and changelog?

it shouldnt be a sep change.  it should be squashed into the broken
one so that the result works.
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Michal Marek]

On 28.10.2010 01:10, Mike Frysinger wrote:
> On Wed, Oct 27, 2010 at 18:46, Michal Marek wrote:
>> On 27.10.2010 20:23, Mike Frysinger wrote:
>>> can we get this change dropped from linux-next until someone gets a
>>> chance to fix it ?
>>
>> Sorry I missed this thread. So your last patch
>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>> failure? Can you submit it with a proper Signed-off-by and changelog?
> 
> it shouldnt be a sep change.  it should be squashed into the broken
> one so that the result works.

The breakage already happened and I don't want to rewind the branch now.
The worst that can happen is that if you bisect into ffe8018 you'll get
a tree that does not build on Blackfin. The previous commit works and
the next will do as well if you submit the patch.

Michal

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Wed, Oct 27, 2010 at 19:33, Michal Marek wrote:
> On 28.10.2010 01:10, Mike Frysinger wrote:
>> On Wed, Oct 27, 2010 at 18:46, Michal Marek wrote:
>>> On 27.10.2010 20:23, Mike Frysinger wrote:
>>>> can we get this change dropped from linux-next until someone gets a
>>>> chance to fix it ?
>>>
>>> Sorry I missed this thread. So your last patch
>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>>
>> it shouldnt be a sep change.  it should be squashed into the broken
>> one so that the result works.
>
> The breakage already happened and I don't want to rewind the branch now.

if it isnt going to be merged until 2.6.38 merge window, i dont see
what the problem is with squashing a change into it.

> The worst that can happen is that if you bisect into ffe8018 you'll get
> a tree that does not build on Blackfin.

and h8300.  i thought there was another symbol prefix arch than just
these two, but my grep isnt showing it atm.

 The previous commit works and
> the next will do as well if you submit the patch.

if my change is going in after your bad commit, then you can squash it
with a simple `git commit --amend`.
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Michal Marek]

On 28.10.2010 01:58, Mike Frysinger wrote:
> On Wed, Oct 27, 2010 at 19:33, Michal Marek wrote:
>> On 28.10.2010 01:10, Mike Frysinger wrote:
>>> On Wed, Oct 27, 2010 at 18:46, Michal Marek wrote:
>>>> Sorry I missed this thread. So your last patch
>>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>>>
>>> it shouldnt be a sep change.  it should be squashed into the broken
>>> one so that the result works.
>>
>> The breakage already happened and I don't want to rewind the branch now.
> 
> if it isnt going to be merged until 2.6.38 merge window, i dont see
> what the problem is with squashing a change into it.

kbuild-2.6.git#kbuild has stuff meant for 2.6.37, In fact I'll be
sending a pull request to Linus today. It would be great to sort the
Blackfin & h8300 build failure first, though.


>  The previous commit works and
>> the next will do as well if you submit the patch.
> 
> if my change is going in after your bad commit, then you can squash it
> with a simple `git commit --amend`.

I know how to rewrite the branch, I just don't want to do it needlessly
so that 'git pull' still works for people tracking the branch.

Michal

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Thu, Oct 28, 2010 at 08:08, Michal Marek wrote:
> On 28.10.2010 01:58, Mike Frysinger wrote:
>> On Wed, Oct 27, 2010 at 19:33, Michal Marek wrote:
>>> On 28.10.2010 01:10, Mike Frysinger wrote:
>>>> On Wed, Oct 27, 2010 at 18:46, Michal Marek wrote:
>>>>> Sorry I missed this thread. So your last patch
>>>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>>>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>>>>
>>>> it shouldnt be a sep change.  it should be squashed into the broken
>>>> one so that the result works.
>>>
>>> The breakage already happened and I don't want to rewind the branch now.
>>
>> if it isnt going to be merged until 2.6.38 merge window, i dont see
>> what the problem is with squashing a change into it.
>
> kbuild-2.6.git#kbuild has stuff meant for 2.6.37, In fact I'll be
> sending a pull request to Linus today. It would be great to sort the
> Blackfin & h8300 build failure first, though.

so you sent a pull request to Linus knowing full well that the
contents of your merge will completely break two architectures ?

>>  The previous commit works and
>>> the next will do as well if you submit the patch.
>>
>> if my change is going in after your bad commit, then you can squash it
>> with a simple `git commit --amend`.
>
> I know how to rewrite the branch, I just don't want to do it needlessly
> so that 'git pull' still works for people tracking the branch.

keeping git bisect sane is not what i would classify as "needlessly"

at any rate, i'm leaving now for vacation and wont be back for like
two weeks.  feel free to take any of the changes i posted earlier
under whatever authorship/sob you want.
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Thu, Oct 28, 2010 at 15:46, Mike Frysinger wrote:
> On Thu, Oct 28, 2010 at 08:08, Michal Marek wrote:
>> On 28.10.2010 01:58, Mike Frysinger wrote:
>>>  The previous commit works and
>>>> the next will do as well if you submit the patch.
>>>
>>> if my change is going in after your bad commit, then you can squash it
>>> with a simple `git commit --amend`.
>>
>> I know how to rewrite the branch, I just don't want to do it needlessly
>> so that 'git pull' still works for people tracking the branch.
>
> keeping git bisect sane is not what i would classify as "needlessly"

plus, there is no requirement that your current tree be what Linus
pulls.  add my patch to your branch-that-may-not-be-rebased, then
create a new branch with those two squashed, and have Linus pull that.
 your main branch will pick up a merge commit, but who cares.
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Sam Ravnborg]

On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
> On 27.10.2010 20:23, Mike Frysinger wrote:
> > can we get this change dropped from linux-next until someone gets a
> > chance to fix it ?
> 
> Sorry I missed this thread. So your last patch
> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
> failure? Can you submit it with a proper Signed-off-by and changelog?

Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534

The one that fix up the cppflags usage.

I think this will solve the issue with blackfin nicely - and
make use of cppflags more as expected.

	Sam

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Thu, Oct 28, 2010 at 16:35, Sam Ravnborg wrote:
> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
>> On 27.10.2010 20:23, Mike Frysinger wrote:
>> > can we get this change dropped from linux-next until someone gets a
>> > chance to fix it ?
>>
>> Sorry I missed this thread. So your last patch
>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>> failure? Can you submit it with a proper Signed-off-by and changelog?
>
> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
>
> The one that fix up the cppflags usage.
>
> I think this will solve the issue with blackfin nicely - and
> make use of cppflags more as expected.

but then i followed up that the Makefile code exists to strip out
quotes because the CPP cannot do it for us and we need a value sans
quotes:
http://lkml.org/lkml/2010/10/19/538
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Thu, Oct 28, 2010 at 16:42, Mike Frysinger wrote:
> On Thu, Oct 28, 2010 at 16:35, Sam Ravnborg wrote:
>> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
>>> On 27.10.2010 20:23, Mike Frysinger wrote:
>>> > can we get this change dropped from linux-next until someone gets a
>>> > chance to fix it ?
>>>
>>> Sorry I missed this thread. So your last patch
>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>>
>> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
>>
>> The one that fix up the cppflags usage.
>>
>> I think this will solve the issue with blackfin nicely - and
>> make use of cppflags more as expected.
>
> but then i followed up that the Makefile code exists to strip out
> quotes because the CPP cannot do it for us and we need a value sans
> quotes:
> http://lkml.org/lkml/2010/10/19/538

for due diligence, adding those two changes breaks building like so:
  LD      .tmp_vmlinux1
.../bfin-uclinux/bin/ld.real: cannot find _
make: *** [.tmp_vmlinux1] Error 1

and if we look at the generated vmlinux.lds, we indeed see the quotes
causing problems:
  . = ALIGN(8); "_"__lock_text_start = .; *(.spinlock.text)
"_"__lock_text_end = .;
  . = ALIGN(8); "_"__kprobes_text_start = .; *(.kprobes.text)
"_"__kprobes_text_end = .;
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Sam Ravnborg]

On Thu, Oct 28, 2010 at 04:42:13PM -0400, Mike Frysinger wrote:
> On Thu, Oct 28, 2010 at 16:35, Sam Ravnborg wrote:
> > On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
> >> On 27.10.2010 20:23, Mike Frysinger wrote:
> >> > can we get this change dropped from linux-next until someone gets a
> >> > chance to fix it ?
> >>
> >> Sorry I missed this thread. So your last patch
> >> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
> >> failure? Can you submit it with a proper Signed-off-by and changelog?
> >
> > Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
> >
> > The one that fix up the cppflags usage.
> >
> > I think this will solve the issue with blackfin nicely - and
> > make use of cppflags more as expected.
> 
> but then i followed up that the Makefile code exists to strip out
> quotes because the CPP cannot do it for us and we need a value sans
> quotes:
> http://lkml.org/lkml/2010/10/19/538

Yep - but this was only relevant for patch number two.
I would expect the first patch to solve it.

I may look at it in a few weeks time.

	Sam

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Michal Marek]

On 28.10.2010 22:35, Sam Ravnborg wrote:
> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
>> On 27.10.2010 20:23, Mike Frysinger wrote:
>>> can we get this change dropped from linux-next until someone gets a
>>> chance to fix it ?
>>
>> Sorry I missed this thread. So your last patch
>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>> failure? Can you submit it with a proper Signed-off-by and changelog?
> 
> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
> 
> The one that fix up the cppflags usage.
> 
> I think this will solve the issue with blackfin nicely - and
> make use of cppflags more as expected.

As Mike noted - your patch does not strip the double quotes. And Mike's
patch is really minimal, it just adds the SYMBOL_PREFIX definition to
_a_flags. I'll look at your patch after this merge window.

Michal

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Thu, Oct 28, 2010 at 17:19, Michal Marek wrote:
> On 28.10.2010 22:35, Sam Ravnborg wrote:
>> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
>>> On 27.10.2010 20:23, Mike Frysinger wrote:
>>>> can we get this change dropped from linux-next until someone gets a
>>>> chance to fix it ?
>>>
>>> Sorry I missed this thread. So your last patch
>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>>
>> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
>>
>> The one that fix up the cppflags usage.
>>
>> I think this will solve the issue with blackfin nicely - and
>> make use of cppflags more as expected.
>
> As Mike noted - your patch does not strip the double quotes. And Mike's
> patch is really minimal, it just adds the SYMBOL_PREFIX definition to
> _a_flags. I'll look at your patch after this merge window.

why am i seeing __initramfs_size failures in mainline now ?
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Sat, Nov 13, 2010 at 18:17, Mike Frysinger wrote:
> On Thu, Oct 28, 2010 at 17:19, Michal Marek wrote:
>> On 28.10.2010 22:35, Sam Ravnborg wrote:
>>> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
>>>> On 27.10.2010 20:23, Mike Frysinger wrote:
>>>>> can we get this change dropped from linux-next until someone gets a
>>>>> chance to fix it ?
>>>>
>>>> Sorry I missed this thread. So your last patch
>>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>>>
>>> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
>>>
>>> The one that fix up the cppflags usage.
>>>
>>> I think this will solve the issue with blackfin nicely - and
>>> make use of cppflags more as expected.
>>
>> As Mike noted - your patch does not strip the double quotes. And Mike's
>> patch is really minimal, it just adds the SYMBOL_PREFIX definition to
>> _a_flags. I'll look at your patch after this merge window.
>
> why am i seeing __initramfs_size failures in mainline now ?

ping ... it looks like no one merged the VMLINUX_SYMBOL() changes in
usr/initramfs_data.S proposed by Hendrik
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Andrew Morton]

On Wed, 24 Nov 2010 03:40:51 -0500
Mike Frysinger <vapier.adi@gmail.com> wrote:

> On Sat, Nov 13, 2010 at 18:17, Mike Frysinger wrote:
> > On Thu, Oct 28, 2010 at 17:19, Michal Marek wrote:
> >> On 28.10.2010 22:35, Sam Ravnborg wrote:
> >>> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
> >>>> On 27.10.2010 20:23, Mike Frysinger wrote:
> >>>>> can we get this change dropped from linux-next until someone gets a
> >>>>> chance to fix it ?
> >>>>
> >>>> Sorry I missed this thread. So your last patch
> >>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
> >>>> failure? Can you submit it with a proper Signed-off-by and changelog?
> >>>
> >>> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
> >>>
> >>> The one that fix up the cppflags usage.
> >>>
> >>> I think this will solve the issue with blackfin nicely - and
> >>> make use of cppflags more as expected.
> >>
> >> As Mike noted - your patch does not strip the double quotes. And Mike's
> >> patch is really minimal, it just adds the SYMBOL_PREFIX definition to
> >> _a_flags. I'll look at your patch after this merge window.
> >
> > why am i seeing __initramfs_size failures in mainline now ?
> 
> ping ... it looks like no one merged the VMLINUX_SYMBOL() changes in
> usr/initramfs_data.S proposed by Hendrik

Well I found and forward-ported the below, from October.

Problem is, the changelog didn't describe the alleged "build break" and
it's unclear whether the fix is needed in mainline, in 2.6.36 or is
just fixing some bug which was introduced by some other
perhaps-not-applied patch.

Help?  What's going on here?


From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>

Define the __initramfs_size variable using VMLINUX_SYMBOL() to take care
of symbol-prefixed architectures, for example, blackfin.

Depending on the CONFIG_SYMBOL_PREFIX configuration option, define the
SYMBOL_PREFIX symbol which is evaluated by VMLINUX_SYMBOL().

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Mike Frysinger <vapier.adi@gmail.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>, 
Cc: Michal Marek <mmarek@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 usr/Makefile         |    3 +++
 usr/initramfs_data.S |    5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff -puN usr/Makefile~initramfs-fix-build-break-on-symbol-prefixed-archs usr/Makefile
--- a/usr/Makefile~initramfs-fix-build-break-on-symbol-prefixed-archs
+++ a/usr/Makefile
@@ -19,6 +19,9 @@ suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZ
 suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZO)   = .lzo
 
 AFLAGS_initramfs_data.o += -DINITRAMFS_IMAGE="usr/initramfs_data.cpio$(suffix_y)"
+ifdef CONFIG_SYMBOL_PREFIX
+AFLAGS_initramfs_data.o += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
+endif
 
 # Generate builtin.o based on initramfs_data.o
 obj-$(CONFIG_BLK_DEV_INITRD) := initramfs_data.o
diff -puN usr/initramfs_data.S~initramfs-fix-build-break-on-symbol-prefixed-archs usr/initramfs_data.S
--- a/usr/initramfs_data.S~initramfs-fix-build-break-on-symbol-prefixed-archs
+++ a/usr/initramfs_data.S
@@ -22,14 +22,15 @@
 */
 
 #include <linux/stringify.h>
+#include <asm-generic/vmlinux.lds.h>
 
 .section .init.ramfs,"a"
 __irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)
 __irf_end:
 .section .init.ramfs.info,"a"
-.globl __initramfs_size
-__initramfs_size:
+.globl VMLINUX_SYMBOL(__initramfs_size)
+VMLINUX_SYMBOL(__initramfs_size):
 #ifdef CONFIG_64BIT
 	.quad __irf_end - __irf_start
 #else
_

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Mon, Nov 29, 2010 at 17:38, Andrew Morton wrote:
> On Wed, 24 Nov 2010 03:40:51 -0500 Mike Frysinger wrote:
>> On Sat, Nov 13, 2010 at 18:17, Mike Frysinger wrote:
>> > On Thu, Oct 28, 2010 at 17:19, Michal Marek wrote:
>> >> On 28.10.2010 22:35, Sam Ravnborg wrote:
>> >>> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
>> >>>> On 27.10.2010 20:23, Mike Frysinger wrote:
>> >>>>> can we get this change dropped from linux-next until someone gets a
>> >>>>> chance to fix it ?
>> >>>>
>> >>>> Sorry I missed this thread. So your last patch
>> >>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
>> >>>> failure? Can you submit it with a proper Signed-off-by and changelog?
>> >>>
>> >>> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
>> >>>
>> >>> The one that fix up the cppflags usage.
>> >>>
>> >>> I think this will solve the issue with blackfin nicely - and
>> >>> make use of cppflags more as expected.
>> >>
>> >> As Mike noted - your patch does not strip the double quotes. And Mike's
>> >> patch is really minimal, it just adds the SYMBOL_PREFIX definition to
>> >> _a_flags. I'll look at your patch after this merge window.
>> >
>> > why am i seeing __initramfs_size failures in mainline now ?
>>
>> ping ... it looks like no one merged the VMLINUX_SYMBOL() changes in
>> usr/initramfs_data.S proposed by Hendrik
>
> Well I found and forward-ported the below, from October.
>
> Problem is, the changelog didn't describe the alleged "build break"

his e-mail from October you found contains the context showing the
build failure:
  i'm pretty sure this breaks on every symbol-prefixed arch.  at least,
  it broke every Blackfin board:
  init/built-in.o: In function `populate_rootfs':
  init/initramfs.c:(.init.text+0x2548): undefined reference to
`__initramfs_size'
  init/initramfs.c:(.init.text+0x254e): undefined reference to
`__initramfs_size'
  make: *** [.tmp_vmlinux1] Error 1

> it's unclear whether the fix is needed in mainline, in 2.6.36 or is
> just fixing some bug which was introduced by some other
> perhaps-not-applied patch.

it was caused by changes Michal added post 2.6.36, and then pushed to
Linus without bothering to address the reports sent to him.  so it
needs to be in before 2.6.37 is released.
-mike

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Michal Marek]

On Mon, Nov 29, 2010 at 06:29:37PM -0500, Mike Frysinger wrote:
> On Mon, Nov 29, 2010 at 17:38, Andrew Morton wrote:
> > On Wed, 24 Nov 2010 03:40:51 -0500 Mike Frysinger wrote:
> >> On Sat, Nov 13, 2010 at 18:17, Mike Frysinger wrote:
> >> > On Thu, Oct 28, 2010 at 17:19, Michal Marek wrote:
> >> >> On 28.10.2010 22:35, Sam Ravnborg wrote:
> >> >>> On Thu, Oct 28, 2010 at 12:46:31AM +0200, Michal Marek wrote:
> >> >>>> On 27.10.2010 20:23, Mike Frysinger wrote:
> >> >>>>> can we get this change dropped from linux-next until someone gets a
> >> >>>>> chance to fix it ?
> >> >>>>
> >> >>>> Sorry I missed this thread. So your last patch
> >> >>>> (http://lkml.org/lkml/2010/10/19/488) did fix the Blackfin build
> >> >>>> failure? Can you submit it with a proper Signed-off-by and changelog?
> >> >>>
> >> >>> Did you see the patch I posted in: http://lkml.org/lkml/2010/10/19/534
> >> >>>
> >> >>> The one that fix up the cppflags usage.
> >> >>>
> >> >>> I think this will solve the issue with blackfin nicely - and
> >> >>> make use of cppflags more as expected.
> >> >>
> >> >> As Mike noted - your patch does not strip the double quotes. And Mike's
> >> >> patch is really minimal, it just adds the SYMBOL_PREFIX definition to
> >> >> _a_flags. I'll look at your patch after this merge window.
> >> >
> >> > why am i seeing __initramfs_size failures in mainline now ?
> >>
> >> ping ... it looks like no one merged the VMLINUX_SYMBOL() changes in
> >> usr/initramfs_data.S proposed by Hendrik

Argh, yes. I only merged your patch to use -DSYMBOL_PREFIX when preprocessing
.S files ("initramfs: Fix build break on symbol-prefixed archs") as d63f6d1,
but did not realize that the main part of Hendrik's patch is missing :-/.

> >
> > Well I found and forward-ported the below, from October.

I deleted the Makefile change, which is now obsoleted by d63f6d1, the
result would look like below. Mike, does mainline with this patch build
on Blackfin now?

Michal

From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Subject: [PATCH] initramfs: Really fix build break on symbol-prefixed archs

Define the __initramfs_size variable using VMLINUX_SYMBOL() to take care
of symbol-prefixed architectures, for example, blackfin.

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Mike Frysinger <vapier.adi@gmail.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
Cc: Michal Marek <mmarek@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[mmarek: leave out Makefile change, since d63f6d1 already takes care of the
 SYMBOL_PREFIX define]
Signed-off-by: Michal Marek <mmarek@suse.cz>

diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index 792a750..c14322d 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -22,14 +22,15 @@
 */
 
 #include <linux/stringify.h>
+#include <asm-generic/vmlinux.lds.h>
 
 .section .init.ramfs,"a"
 __irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)
 __irf_end:
 .section .init.ramfs.info,"a"
-.globl __initramfs_size
-__initramfs_size:
+.globl VMLINUX_SYMBOL(__initramfs_size)
+VMLINUX_SYMBOL(__initramfs_size):
 #ifdef CONFIG_64BIT
 	.quad __irf_end - __irf_start
 #else

Re: [PATCH] initramfs: Fix build break on symbol-prefixed archs

[Mike Frysinger]

On Tue, Nov 30, 2010 at 10:36, Michal Marek wrote:
> I deleted the Makefile change, which is now obsoleted by d63f6d1, the
> result would look like below. Mike, does mainline with this patch build
> on Blackfin now?

yes, it fixes things for me.  thanks !
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-mike

Re: [PATCH 0/2] initramfs: Cleanup and fix initramfs size calculation

[Michal Marek]

On 31.8.2010 10:23, Hendrik Brueckner wrote:
> Hello Michal, Sam,
> 
> I did not see any further comments on the patch series about the
> initramfs cleanup and new size calculation.

Sorry about that, I don't always have as much time for kbuild as I would
like to have :(.


> This is a resend and now I am asking you for your review and ack.
> Please let me know if you have questions or comments.

I like the cleanup patch and the thing still survives (very basic)
testing, so
Acked-by: Michal Marek <mmarek@suse.cz>

I'm wondering which tree should these patches go through... Peter, will
you apply them to some branch of tip.git or should I apply them to
kbuild-2.6.git?

Michal

Re: [PATCH 0/2] initramfs: Cleanup and fix initramfs size calculation

[H. Peter Anvin]

On 08/31/2010 07:08 AM, Michal Marek wrote:
> On 31.8.2010 10:23, Hendrik Brueckner wrote:
>> Hello Michal, Sam,
>>
>> I did not see any further comments on the patch series about the
>> initramfs cleanup and new size calculation.
> 
> Sorry about that, I don't always have as much time for kbuild as I would
> like to have :(.
> 
> 
>> This is a resend and now I am asking you for your review and ack.
>> Please let me know if you have questions or comments.
> 
> I like the cleanup patch and the thing still survives (very basic)
> testing, so
> Acked-by: Michal Marek <mmarek@suse.cz>
> 
> I'm wondering which tree should these patches go through... Peter, will
> you apply them to some branch of tip.git or should I apply them to
> kbuild-2.6.git?
> 

[Sorry for late reply, I have been away]

It's up to you, but I'm happy to apply them to a tip branch with your ack.

	-hpa