Skip to contentSkip to conversation

2.6.8-rc2-mm1 link errors

DISCUSSION Dave Hansen 4 participants 7 messages Jul 28, 2004 – Jul 29, 2004 Kbuild

lore
Share & tools
lore

Dave Hansen

author
#0 lore raw

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

#1 lore raw
Quoted 8 lines · 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:

Quoted 6 lines

<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?

author
#2 lore raw
Quoted 12 lines · Andrew Morton
Quoted 11 lines · 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>

Quoted 6 lines
Quoted 3 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 <[email protected]>

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

---

 25-akpm/Makefile |    8 ++++++++
 1 files changed, 8 insertions(+)
Makefile renamed from Makefile~handle-undefined-symbols +8 -0
diff -puN Makefile~handle-undefined-symbols Makefile
@@ -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

author
#3 lore raw
In reply to Andrew Morton
Quoted 2 lines · Andrew Morton

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

arch/i386/kernel/irq.c +6 -2
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
@@ -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
#4 lore raw
Quoted 28 lines · Dave Hansen
Quoted 2 lines · Andrew Morton

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

Quoted 6 lines

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?

Signature · 1 line
Mathematics is the supreme nostalgia of our time.
author
#5 lore raw
Quoted 4 lines · Matt Mackall
Quoted 1 line · Dave Hansen

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.

Quoted 1 line

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

#6 lore raw
In reply to Dave Hansen
Quoted 28 lines · Dave Hansen
Quoted 2 lines · Andrew Morton

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

Quoted 6 lines

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.

Quoted 1 line

-- Dave

cu
Adrian

Signature · 4 lines
       "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