Skip to contentSkip to conversation

initramfs: Cleanup and fix initramfs size calculation

PATCH In review Hendrik Brueckner 7 participants 32 messages Aug 31, 2010 – Dec 2, 2010

Subsystems (3)
VFS Kbuild Generic include/asm header files
lore
Share & tools
lore

Hendrik Brueckner

author
#0 lore raw

cover initramfs: Cleanup and fix initramfs size calculation

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

author
#1 lore raw

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

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 <[email protected]>
---
 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(-)
usr/Makefile +4 -2
@@ -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
usr/initramfs_data.S +3 -2
@@ -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)
usr/initramfs_data.bz2.S deleted +0 -29
@@ -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"
usr/initramfs_data.gz.S deleted +0 -29
@@ -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"
usr/initramfs_data.lzma.S deleted +0 -29
@@ -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"
usr/initramfs_data.lzo.S deleted +0 -29
@@ -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"
author
#2 lore raw

PATCH 2/2 initramfs: Fix initramfs size calculation

In reply to Hendrik Brueckner

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 <[email protected]>
Signed-off-by Hendrik Brueckner <[email protected]>
---
 include/asm-generic/vmlinux.lds.h |    3 ++-
 init/initramfs.c                  |    9 ++++-----
 usr/initramfs_data.S              |   16 +++++++++++-----
 3 files changed, 17 insertions(+), 11 deletions(-)
include/asm-generic/vmlinux.lds.h +2 -1
@@ -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
init/initramfs.c +4 -5
@@ -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);
usr/initramfs_data.S +11 -5
@@ -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
Reviewed-by on v1 2/2
#3 lore raw

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

Quoted 40 lines · Hendrik Brueckner

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.

Quoted 2 lines
Signed-off-by Michael Holzheu <[email protected]>
Signed-off-by Hendrik Brueckner <[email protected]>

This patch looks good for me too,

Reviewed-by WANG Cong <[email protected]>

I think Michal will take this into kbuild tree.

Thanks!

#4 lore raw

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

In reply to Hendrik Brueckner
Quoted 8 lines · Hendrik Brueckner
usr/initramfs_data.S +0 -0
@@ -28,4 +24,14 @@ SECTIONS
  #include <linux/stringify.h>

 .section .init.ramfs,"a"
+__irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)

usr/initramfs_data.S SECTIONS · line 37

Quoted 9 lines
usr/initramfs_data.S +9 -0
+__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

author
#5 lore raw

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

Hi Mike,

Quoted 9 lines · Mike Frysinger

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 <[email protected]>
---
 usr/initramfs_data.S |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
usr/initramfs_data.S +3 -2
@@ -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
#6 lore raw

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

Quoted 9 lines · Hendrik Brueckner
Quoted 8 lines · Mike Frysinger

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

Quoted 4 lines
Quoted 1 line

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

author
#7 lore raw

PATCH 1/1 initramfs: Fix build break on symbol-prefixed archs

Hi Mike,

Quoted 10 lines · Mike Frysinger
Quoted 9 lines · Hendrik Brueckner
Quoted 8 lines · Mike Frysinger

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

Quoted 2 lines

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 <[email protected]>
---
 usr/Makefile         |    3 +++
 usr/initramfs_data.S |    5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)
usr/Makefile +3 -0
@@ -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
usr/initramfs_data.S +3 -2
@@ -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
#8 lore raw

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

Quoted 10 lines · Hendrik Brueckner
usr/Makefile +0 -0
@@ -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)"

usr/Makefile +3 -0
+ifdef CONFIG_SYMBOL_PREFIX
+AFLAGS_initramfs_data.o += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
+endif
Quoted 2 lines

 # 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:

scripts/Makefile.lib +3 -1
@@ -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

#9 lore raw

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

Quoted 18 lines · Mike Frysinger
Quoted 10 lines · Hendrik Brueckner
usr/Makefile +0 -0
@@ -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)"

usr/Makefile +3 -0
+ifdef CONFIG_SYMBOL_PREFIX
+AFLAGS_initramfs_data.o += -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
+endif
Quoted 2 lines

 # 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:

scripts/Makefile.lib _c_flags += $(if $(patsubst n%,, \ · line 126

Quoted 8 lines
scripts/Makefile.lib +3 -1
@@ -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

scripts/Makefile.lib +7 -9
index 54fd1b7..1b8f15d 100644
@@ -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)
include/asm-generic/vmlinux.lds.h +2 -2
index 8a92a17..520e4ac 100644
@@ -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. */
scripts/Makefile.lib +0 -4
index 54fd1b7..08e13b1 100644
@@ -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 '/').
#10 lore raw

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

Quoted 3 lines · Sam Ravnborg

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

#11 lore raw

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

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

#12 lore raw

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

Quoted 2 lines · Mike Frysinger

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

#13 lore raw

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

Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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

#14 lore raw

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

Quoted 11 lines · Mike Frysinger
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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

#15 lore raw

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

Quoted 6 lines · Michal Marek
Quoted 5 lines · Mike Frysinger
Quoted 4 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

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.

Quoted 2 lines

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

Quoted 1 line

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

#16 lore raw

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

Quoted 7 lines · Mike Frysinger
Quoted 6 lines · Michal Marek
Quoted 5 lines · Mike Frysinger
Quoted 3 lines · Michal Marek

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?

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

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.

Quoted 5 lines

The previous commit works and

Quoted 1 line

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

#17 lore raw

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

Quoted 11 lines · Michal Marek
Quoted 10 lines · Mike Frysinger
Quoted 9 lines · Michal Marek
Quoted 7 lines · Mike Frysinger
Quoted 3 lines · Michal Marek

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.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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 ?

Quoted 8 lines
Quoted 5 lines

 The previous commit works and

Quoted 1 line

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

#18 lore raw

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

Quoted 5 lines · Mike Frysinger
Quoted 4 lines · Michal Marek
Quoted 3 lines · Mike Frysinger

 The previous commit works and

Quoted 1 line

the next will do as well if you submit the patch.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

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

#19 lore raw

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

In reply to Michal Marek
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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

#20 lore raw

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

Quoted 9 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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?

Quoted 6 lines

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

#21 lore raw

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

Quoted 14 lines · Mike Frysinger
Quoted 13 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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.

Quoted 7 lines
Quoted 2 lines

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

#22 lore raw

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

In reply to Mike Frysinger
Quoted 14 lines · Mike Frysinger
Quoted 13 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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.

Quoted 7 lines
Quoted 2 lines

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

#23 lore raw

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

In reply to Sam Ravnborg
Quoted 9 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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?

Quoted 6 lines

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

#24 lore raw

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

Quoted 12 lines · Michal Marek
Quoted 11 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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

Quoted 8 lines
Quoted 4 lines

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

#25 lore raw

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

Quoted 15 lines · Mike Frysinger
Quoted 14 lines · Michal Marek
Quoted 13 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

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

#26 lore raw

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

Quoted 19 lines · On Wed, 24 Nov 2010 03:40:51 -0500 Mike Frysinger <[email protected]> wrote:
Quoted 18 lines · Mike Frysinger
Quoted 17 lines · Michal Marek
Quoted 15 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

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 <[email protected]>

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 <[email protected]>
Cc Mike Frysinger <[email protected]>
Cc Hendrik Brueckner <[email protected]>,
Cc Michal Marek <[email protected]>
Cc Sam Ravnborg <[email protected]>
Signed-off-by Andrew Morton <[email protected]>

---

 usr/Makefile         |    3 +++
 usr/initramfs_data.S |    5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)
usr/Makefile renamed from usr/Makefile~initramfs-fix-build-break-on-symbol-prefixed-archs +3 -0
diff -puN usr/Makefile~initramfs-fix-build-break-on-symbol-prefixed-archs 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
usr/initramfs_data.S renamed from usr/initramfs_data.S~initramfs-fix-build-break-on-symbol-prefixed-archs +3 -2
diff -puN usr/initramfs_data.S~initramfs-fix-build-break-on-symbol-prefixed-archs 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

_

#27 lore raw

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

Quoted 24 lines · Andrew Morton
Quoted 23 lines · On Wed, 24 Nov 2010 03:40:51 -0500 Mike Frysinger wrote:
Quoted 22 lines · Mike Frysinger
Quoted 20 lines · Michal Marek
Quoted 9 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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?

Quoted 6 lines

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.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 3 lines

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

#28 lore raw

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

Quoted 21 lines · Mike Frysinger
Quoted 20 lines · Andrew Morton
Quoted 19 lines · On Wed, 24 Nov 2010 03:40:51 -0500 Mike Frysinger wrote:
Quoted 18 lines · Mike Frysinger
Quoted 17 lines · Michal Marek
Quoted 15 lines · Sam Ravnborg
Quoted 7 lines · Michal Marek
Quoted 2 lines · Mike Frysinger

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.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

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 :-/.

Quoted 2 lines
Quoted 2 lines

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 <[email protected]>
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 <[email protected]>
Cc Mike Frysinger <[email protected]>
Cc Hendrik Brueckner <[email protected]>,
Cc Michal Marek <[email protected]>
Cc Sam Ravnborg <[email protected]>
Signed-off-by Andrew Morton <[email protected]>

[mmarek: leave out Makefile change, since d63f6d1 already takes care of the
SYMBOL_PREFIX define]

Signed-off-by Michal Marek <[email protected]>
usr/initramfs_data.S +3 -2
index 792a750..c14322d 100644
@@ -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
#29 lore raw

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

Quoted 3 lines · Michal Marek

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 <[email protected]>

-mike

Acked-by on the v1 series
#30 lore raw
In reply to Hendrik Brueckner
Quoted 4 lines · Hendrik Brueckner

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 :(.

Quoted 2 lines

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 <[email protected]>

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

#31 lore raw
Quoted 13 lines · Michal Marek
Quoted 4 lines · Hendrik Brueckner

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 :(.

Quoted 2 lines

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.

Quoted 8 lines

I like the cleanup patch and the thing still survives (very basic) testing, so

Acked-by Michal Marek <[email protected]>

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