On Thu, 20 Dec 2001 22:57:12 +0300,
Andrey Nekrasov <andy@xxxxxxxxx> wrote:
>Hello.
>
>make clean
>make menuconfig
>make dep
>make bzImage
>...
>drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols =
>in
>discarded section .text.exit'
>drivers/net/net.o(.data+0x194): undefined reference to `local symbols in =
>discarded
>section .text.exit'
Short answer: Downgrade binutils to previous release or wait for 2.4.17.
Long answer:
Some bits of the kernel are compiled into sections which are discarded
at link time because they are not used in the kernel, only in modules
or with device hot plugging. These functions are marked __exit or
__devexit, with similar markers for data.
Old versions of binutils did not detect references from an existing
section to data or code that had been discarded. Instead of flagging
an error, they silently replaced the reference with an offset from the
start of a non-existent section starting from address 0. This caused
oops if the reference was ever used. It also caused some architecture
builds (ia64 in particular) to fail if the reference from high kernel
memory to a low address could not fit into a PC relative branch. In
many cases the dangling references were coding errors, with code
calling into __exit functions which were not guaranteed to exist at run
time.
After I reported this bug, H. J. Lu changed binutils to detect
references from existing sections to discarded sections and flag an
error at link time. That way any bad coding would be found immediately
instead of generating semi-random oops.
This change to binutils is good, but before we can use it to catch the
bad coding practices, we have to remove some other dangling references
which are generating false positives. In particular the 'remove'
element of some structures points to a __devexit function, that
reference must be changed to NULL when the __devexit function is
discarded. I added wrapper __devexit_p to 2.4.17-pre kernels and
changed the remove structure elements to use __devexit_p.
Using __devexit_p and the new binutils found several places where
invalid code had been used. It looks pretty stable now in 2.4.17-rc2,
except for a couple of problem cases on sparc and possibly the preempt
patch. I am looking into those problems.
|