Messages in this thread | | | Date | Sat, 10 Apr 2004 15:33:07 -0400 | From | Brian Gerst <> | Subject | Re: [RFC] Force build error on undefined symbols |
| |
Russell King wrote: > Hi, > > I've checked the date, and it isn't April Fools day. I wish it was > though. > > It appears that all binutils versions for ARM which are capable of > building 2.6 kernels which have been tested so far contain a serious > bug - it is possible to successfully link an object and still have > various symbols undefined. Currently, these binutils have been > tested on ARM (as cross-compilers and/or native) and found wanting: > > GNU assembler 2.13.90.0.18 20030206 > GNU assembler 2.14 20030612 > GNU assembler 2.14.90 20031229 > GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux > Assembleur GNU 2.15.90.0.1 20040303 > > So far, we have discovered two cases: > > 1. When building a certain file, an undefined symbolic constant > (TI_USED_CP) ended up in the symbol table without a relocation, > and the value the assembler decided to use was '0'. The effect > of this is that we ended up setting bits in thread_info->flags. > > This appears to be a binutils "as" error. > > 2. When building the decompressor for ARM kernels, GCC appears to > inexplicably emit ".global" directives for symbols not defined > in the files being built, even though the symbols themselves are > not actually used. I'm not sure whether this is a real bug; > binutils on x86 appears to accept and link such objects. > > In both cases, the linker successfully created executable programs > which ran. In the first case, it is a silent error; the kernel had > been linked, and able to run, but the program is not correct. > > Obviously, the one true correct solution is to fix the toolchain and > upgrade to the latest version. However, since we have potentially > multiple binutils versions spread across more than a year affected, > I think we need to detect such errors as well. > > Therefore, I propose the following patch to detect undefined symbols > in the final image and force an error if this is the case. > > Comments?
How about adding --no-undefined to LDFLAGS_vmlinux instead?
-- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |