Given this small C source /* foo.c */ extern char global_var; main () { global_var = 1; } /* EOF */ should result in an executable with undefined symbols, shouldn't it? binutils-2.9.1/ld fails to recognize this and produces an executable without any complaint, which will core dump when running, of course. I've built the stuff using: $ env CC=sparc-sun-solaris2.5.1-gcc 'CFLAGS=-O0 -g ' LDFLAGS=-g ' \ LINGUAS=de es fr it' 'INSTALL=/tools/gnu/bin/install -c' \ 'INSTALL_DATA=/tools/gnu/bin/install -c -m 644' \ 'INSTALL_PROGRAM=/tools/gnu/bin/install -c -m 755' \ /bin/sh ../binutils-2.9.1/configure --host=sparc-sun-solaris2.5.1 \ --target=delta88 --build=sparc-sun-solaris2.5.1 \ --srcdir=../binutils-2.9.1 \ --prefix=/u/b60/manfred/gnu/sparc-sun-solaris2.5.1 \ --enable-targets=delta88,m68k-motorola-sysv,m88k-motorola-sysv3,m68k-unknown-ieee \ --enable-shared=no --verbose $ gmake -wk SHELL=/u/b60/manfred/gnu/sparc-sun-solaris2.5.1/bin/bash all check info To simplify checking, fixing (I've already debugged, but cannot find the reason), ... I've appended a small 88k assembler source, which can be used to demonstrate the problem. file "foo.s" text align 8 global __start __start: or.u r13,r0,hi16(_global_var) or r12,r0,1 st.b r12,r13,lo16(_global_var) jmp r1 $ ./gas/as-new -o foo.o foo.s $ ./binutils/nm-new foo.o 00000010 b .bss 00000010 d .data 00000000 t .text 00000000 T __start U _global_var Looks good, so far; but, when linking, NO complaint: $ ./ld/ld-new -o a.out foo.o $ ./binutils/nm-new a.out 004000c8 b .bss 004000c8 d .data 000200b8 t .text 000200c8 T __.fini_end 000200c8 T __.fini_start 000200b8 T __.init.end 000200b8 T __.init.start 000200c8 T __.initp.end 000200c8 T __.initp.start 000200c8 T __.tdesc_start 000200b8 T __.text.start 000200c8 T __.text_end 004000c8 B __end 000200b8 T __start 004000c8 D _edata 004000c8 B _end 000200c8 T _etext U _global_var As you can see, "global_var" is still undefined. This problem isn't new, I can easily reproduce it with binutils-2.7 - funnily, we've been using this linker already without problems for many million lines of C/C++ code :-? Any ideas? Thanks -- Manfred Hollstein If you have any questions about GNU software: Hindenburgstr. 13/1 < mailto:manfred@s-direktnet.de > 75446 Wiernsheim, FRG < http://www.s-direktnet.de/HomePages/manfred/ > PGP key: < http://www.s-direktnet.de/HomePages/manfred/manfred.asc >
Date: Tue, 7 Jul 1998 12:59:39 +0200 (MET DST) From: Manfred Hollstein <manfred@s-direktnet.de> Given this small C source /* foo.c */ extern char global_var; main () { global_var = 1; } /* EOF */ should result in an executable with undefined symbols, shouldn't it? ... As you can see, "global_var" is still undefined. This problem isn't new, I can easily reproduce it with binutils-2.7 - funnily, we've been using this linker already without problems for many million lines of C/C++ code :-? Judging by the howto fields in coff-m88k.c, all m88k relocs are handled by the function m88k_special_reloc in that file. That function does not seem to check for undefined symbols when handling the R_HVRT16 and R_LVRT16 reloc types. Since it returns bfd_reloc_ok for those types, no further checking will be done. It should return bfd_reloc_undefined instead for an undefined symbol. See bfd_perform_relocation. Ian
On Tue, 7 July 1998, 11:27:12, ian@cygnus.com wrote: > Date: Tue, 7 Jul 1998 12:59:39 +0200 (MET DST) > From: Manfred Hollstein <manfred@s-direktnet.de> > > Given this small C source > > /* foo.c */ > extern char global_var; > main () { global_var = 1; } > /* EOF */ > > should result in an executable with undefined symbols, shouldn't it? > > ... > > As you can see, "global_var" is still undefined. This problem isn't > new, I can easily reproduce it with binutils-2.7 - funnily, we've been > using this linker already without problems for many million lines of > C/C++ code :-? > > Judging by the howto fields in coff-m88k.c, all m88k relocs are > handled by the function m88k_special_reloc in that file. That > function does not seem to check for undefined symbols when handling > the R_HVRT16 and R_LVRT16 reloc types. Since it returns bfd_reloc_ok > for those types, no further checking will be done. It should return > bfd_reloc_undefined instead for an undefined symbol. See > bfd_perform_relocation. > > Ian Ahh yes, thank you very much for the illumination; I should have recognized this myself as I introduced the m88k_special_reloc function :-( The appended patch works for me; Ian, will you check it into the current development sources? Thanks, Manfred. Wed Jul 8 08:01:32 1998 Manfred Hollstein <manfred@s-direktnet.de> * coff-m88k.c (m88k_special_reloc): Don't loose the information that a symbol is undefined. diff -rup -x CVS -x RCS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el binutils-2.9.1.orig/bfd/coff-m88k.c binutils-2.9.1/bfd/coff-m88k.c --- binutils-2.9.1.orig/bfd/coff-m88k.c Fri May 1 17:48:04 1998 +++ binutils-2.9.1/bfd/coff-m88k.c Wed Jul 8 08:03:11 1998 @@ -117,8 +117,12 @@ m88k_special_reloc (abfd, reloc_entry, s bfd_put_16 (abfd, relocation, (unsigned char *) data + addr); } + /* If we are not producing relocateable output, return an error if + the symbol is not defined. */ + if (bfd_is_und_section (symbol->section) && output_bfd == (bfd *) NULL) + return bfd_reloc_undefined; + return bfd_reloc_ok; - break; default: if (output_bfd != (bfd *) NULL)