bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: as/ld silently creates programs with undefined references/symbols


From: Russell King
Subject: Re: as/ld silently creates programs with undefined references/symbols
Date: Sun, 11 Jul 2004 12:19:44 +0100
User-agent: Mutt/1.2.5.1i

On Sat, Jul 03, 2004 at 09:17:10AM +0100, Nick Clifton wrote:
> > Given that it will be a while until people are using a fixed toolchain,
> > and the range of binutils versions affected, I think it's important to
> > have a way to detect this failure such that kernel developers can filter
> > out the incorrectly built kernels.
> 
> Fair enough.  I assume that you can add this to the kernel build makefiles ?

This is proving particularly difficult since Sparc64 generates
undefined symbols for register declarations.  So far, we've ended
up with something like:

   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;                                                             \

which is not nice, though probably works for the majority of cases
now.

Also, I notice with binutils 2.15, we end up with lots of $a and $d
symbols in the kernel symbol table, eg:

c0020dfc T flush_thread
c0020dfc t $a
c0020e48 t $d
c0020e4c T release_thread
c0020e4c t $a
c0020e5c T copy_thread
c0020eb8 t $d
c0020ec0 T dump_fpu
c0020ec0 t $a
c0020f00 T dump_thread
c0020f00 t $a
c0020fe0 t $d
c0020fe4 t $a
c0020fe4 t kernel_thread_helper

This is really annoying because they interfere with error reporting:

arm-linux-ld -EL -p --no-undefined -X -T arch/arm/kernel/vmlinux.lds.s 
arch/arm/kernel/head.o arch/arm/kernel/init_task.o init/built-in.o 
--start-group usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o 
arch/arm/common/built-in.o arch/arm/mach-footbridge/built-in.o 
arch/arm/nwfpe/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o 
ipc/built-in.o security/built-in.o crypto/built-in.o lib/lib.a 
arch/arm/lib/lib.a lib/built-in.o arch/arm/lib/built-in.o drivers/built-in.o 
sound/built-in.o net/built-in.o --end-group -o .tmp_vmlinux1
local symbol 0: discarded in section `.exit.text' from drivers/built-in.o
drivers/built-in.o(.text+0x6042c): In function `$a':
: relocation truncated to fit: R_ARM_PC24 .exit.text

Function name '$a' is obviously bogus, and it means that there's little
clue as to the real function name.

Also, it doesn't help when the kernel decodes its own backtrace and
tells you that all the functions are called '$a'.  Sure, the kernel
scripts can filter '$a' out, but the point is that it not even binutils
itself copes with these symbols so it just seems completely wrong for
them to be there in the first place.

Looking at the assembly output from gcc, it doesn't define these
symbols - the assembler seems to be generating them itself internally.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core




reply via email to

[Prev in Thread] Current Thread [Next in Thread]