2.6.8-rc2-mm1 link errors

2.6.8-rc2-mm1 link errors

[Dave Hansen]

I'm getting some odd link errors from -rc2-mm1 that don't happen in
-rc1-mm1, or plain -rc2:

          LD      .tmp_vmlinux1
        ldchk: .tmp_vmlinux1: final image has undefined symbols:
        
        
        <bunch of blank lines>
        
        
        make: *** [.tmp_vmlinux1] Error 1
        
Any ideas?

Linux elm3b82 2.6.0-test4-autokern1 #1 SMP Mon Sep 8 08:12:06 PDT 2003
i686 GNU/Linux

Gnu C                  2.95.4
Gnu make               3.80
binutils               2.14.90.0.7
util-linux             2.12
mount                  2.12
module-init-tools      3.1-pre5
e2fsprogs              1.35
PPP                    2.4.2
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Procps                 3.2.1
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.2.1


-- Dave

Re: 2.6.8-rc2-mm1 link errors

[Andrew Morton]

Dave Hansen <haveblue@us.ibm.com> wrote:
>
> I'm getting some odd link errors from -rc2-mm1 that don't happen in
> -rc1-mm1, or plain -rc2:
> 
>           LD      .tmp_vmlinux1
>         ldchk: .tmp_vmlinux1: final image has undefined symbols:
>         
>         
>         <bunch of blank lines>
>         
>         
>         make: *** [.tmp_vmlinux1] Error 1
>         
> Any ideas?

Nope.   Could you take a look at the code in the top-level
Makefile which is doing this, work out why it broke?

Re: 2.6.8-rc2-mm1 link errors

[Dave Hansen]

On Wed, 2004-07-28 at 16:49, Andrew Morton wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote:
> >
> > I'm getting some odd link errors from -rc2-mm1 that don't happen in
> > -rc1-mm1, or plain -rc2:
> > 
> >           LD      .tmp_vmlinux1
> >         ldchk: .tmp_vmlinux1: final image has undefined symbols:
> >         
> >         
> >         <bunch of blank lines>
> >         
> >         
> >         make: *** [.tmp_vmlinux1] Error 1
> >         
> > Any ideas?
> 
> Nope.   Could you take a look at the code in the top-level
> Makefile which is doing this, work out why it broke?

Well, it's this patch.  cc'ing Russell...  

I'd tend to think it's a false-positive, not a real problem that's just
being detected now.  Is the sed part of the patch borked?

-----

From: Russell King <rmk+lkml@arm.linux.org.uk>

The only issue with this is that, when a problem is detected, the
reported symbols will also include the Sparc64 register symbols.

Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/Makefile |    8 ++++++++
 1 files changed, 8 insertions(+)

diff -puN Makefile~handle-undefined-symbols Makefile
--- 25/Makefile~handle-undefined-symbols	2004-07-26 23:24:30.552753872 -0700
+++ 25-akpm/Makefile	2004-07-26 23:24:30.556753264 -0700
@@ -525,6 +525,8 @@ endef
 
 #	set -e makes the rule exit immediately on error
 
+#	Note: Ensure that there are no undefined symbols in the final
+#	linked image.  Not doing this can lead to silent link failures.
 define rule_vmlinux__
 	+set -e;							\
 	$(if $(filter .tmp_kallsyms%,$^),,				\
@@ -536,6 +538,12 @@ define rule_vmlinux__
 	$(if $($(quiet)cmd_vmlinux__),					\
 	  echo '  $($(quiet)cmd_vmlinux__)' &&) 			\
 	$(cmd_vmlinux__);						\
+	if $(OBJDUMP) --syms $@ | egrep -q '^([^R]|R[^E]|RE[^G])[^w]*\*UND\*'; then	\
+		echo 'ldchk: $@: final image has undefined symbols:';	\
+		$(NM) $@ | sed 's/^ *U \(.*\)/  \1/p;d';		\
+		$(RM) -f $@;						\
+		exit 1;							\
+	fi;								\
 	echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
 endef
 
_

-- Dave

Re: 2.6.8-rc2-mm1 link errors

[Dave Hansen]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Wed, 2004-07-28 at 16:49, Andrew Morton wrote:
> Nope.   Could you take a look at the code in the top-level
> Makefile which is doing this, work out why it broke?

It seems to come down to this warning:

arch/i386/kernel/irq.c
{standard input}: Assembler messages:
{standard input}:3565: Warning: setting incorrect section type for
.bss.page_aligned

Which comes from this code in the 4k stacks code:

static char softirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
static char hardirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));

Removing the __section__() fixes it, as does moving to gcc 3.2 or 3.3,
but gcc 2.95 and 3.0 still exhibit the problem.  It seems the 4k stack
developers like newer compilers than I do :) 

The gcc 2.95 section declaration looks like this:
	.section        .bss.page_aligned,"aw",@progbits
while the 3.1 section looks like this:
	.section        .bss.page_aligned,"aw",@nobits

It's definitely a bug that's been fixed:
http://sources.redhat.com/ml/binutils/2002-10/msg00507.html

I've been told that I can fix it with a carefully crafted assembly file
and maybe a change to the linker script, but all that it buys us is a
little space in the uncompressed kernel image.  Plus, the warning will
still be there at compile-time.  

I say, put them back in plain old BSS.  Patch attached.

-- Dave

[-- Attachment #2: irqstacks-nosection-2.6.8-rc2-mm1-0.patch --]
[-- Type: text/x-patch, Size: 1018 bytes --]

diff -rup linux-2.6.8-rc2-mm1/arch/i386/kernel/irq.c linux-2.6.8-rc2-mm1-irqstackbss/arch/i386/kernel/irq.c
--- linux-2.6.8-rc2-mm1/arch/i386/kernel/irq.c	2004-07-28 18:10:40.000000000 -0700
+++ linux-2.6.8-rc2-mm1-irqstackbss/arch/i386/kernel/irq.c	2004-07-28 18:52:41.000000000 -0700
@@ -1118,8 +1118,12 @@ void init_irq_proc (void)
 
 
 #ifdef CONFIG_4KSTACKS
-static char softirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
-static char hardirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
+/* 
+ * These should really be __section__(".bss.page_aligned") as well, but
+ * gcc's 3.0 and earlier don't handle that correctly.
+ */
+static char softirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE)));
+static char hardirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE)));
 
 /*
  * allocate per-cpu stacks for hardirq and for softirq processing

Re: 2.6.8-rc2-mm1 link errors

[Matt Mackall]

On Wed, Jul 28, 2004 at 07:06:13PM -0700, Dave Hansen wrote:
> On Wed, 2004-07-28 at 16:49, Andrew Morton wrote:
> > Nope.   Could you take a look at the code in the top-level
> > Makefile which is doing this, work out why it broke?
> 
> It seems to come down to this warning:
> 
> arch/i386/kernel/irq.c
> {standard input}: Assembler messages:
> {standard input}:3565: Warning: setting incorrect section type for
> .bss.page_aligned
> 
> Which comes from this code in the 4k stacks code:
> 
> static char softirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
> static char hardirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
> 
> Removing the __section__() fixes it, as does moving to gcc 3.2 or 3.3,
> but gcc 2.95 and 3.0 still exhibit the problem.  It seems the 4k stack
> developers like newer compilers than I do :) 
> 
> The gcc 2.95 section declaration looks like this:
> 	.section        .bss.page_aligned,"aw",@progbits
> while the 3.1 section looks like this:
> 	.section        .bss.page_aligned,"aw",@nobits
> 
> It's definitely a bug that's been fixed:
> http://sources.redhat.com/ml/binutils/2002-10/msg00507.html
> 
> I've been told that I can fix it with a carefully crafted assembly file
> and maybe a change to the linker script, but all that it buys us is a
> little space in the uncompressed kernel image.  Plus, the warning will
> still be there at compile-time.  
> 
> I say, put them back in plain old BSS.  Patch attached.

Frankly, I'd rather have the warning if it isn't breaking anything.
Or how about I throw some version conditional magic at it?

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.8-rc2-mm1 link errors

[Dave Hansen]

On Wed, 2004-07-28 at 19:12, Matt Mackall wrote:
> On Wed, Jul 28, 2004 at 07:06:13PM -0700, Dave Hansen wrote:
> > I say, put them back in plain old BSS.  Patch attached.
> 
> Frankly, I'd rather have the warning if it isn't breaking anything.

I just worry that the warning is indicative of something more insidious
than triggering an error from a symbol checker script.

> Or how about I throw some version conditional magic at it?

I thought about including something in compiler-gcc*, but those files
are still pretty simple at this point, and I hate to add more gunk to
them.  It doesn't seem quite worth it to me.  But, if that's the way to
go, I can code it up.

-- Dave

Re: 2.6.8-rc2-mm1 link errors

[Adrian Bunk]

On Wed, Jul 28, 2004 at 07:06:13PM -0700, Dave Hansen wrote:
> On Wed, 2004-07-28 at 16:49, Andrew Morton wrote:
> > Nope.   Could you take a look at the code in the top-level
> > Makefile which is doing this, work out why it broke?
> 
> It seems to come down to this warning:
> 
> arch/i386/kernel/irq.c
> {standard input}: Assembler messages:
> {standard input}:3565: Warning: setting incorrect section type for
> .bss.page_aligned
> 
> Which comes from this code in the 4k stacks code:
> 
> static char softirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
> static char hardirq_stack[NR_CPUS * THREAD_SIZE]  __attribute__((__aligned__(THREAD_SIZE), __section__(".bss.page_aligned")));
> 
> Removing the __section__() fixes it, as does moving to gcc 3.2 or 3.3,
> but gcc 2.95 and 3.0 still exhibit the problem.  It seems the 4k stack
> developers like newer compilers than I do :) 
> 
> The gcc 2.95 section declaration looks like this:
> 	.section        .bss.page_aligned,"aw",@progbits
> while the 3.1 section looks like this:
> 	.section        .bss.page_aligned,"aw",@nobits
> 
> It's definitely a bug that's been fixed:
> http://sources.redhat.com/ml/binutils/2002-10/msg00507.html
> 
> I've been told that I can fix it with a carefully crafted assembly file
> and maybe a change to the linker script, but all that it buys us is a
> little space in the uncompressed kernel image.  Plus, the warning will
> still be there at compile-time.  
> 
> I say, put them back in plain old BSS.  Patch attached.

Thanks, your patch solves a problem with gcc 2.95 in my modular test 
.comnfig I didn't have time to debug.

> -- Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed