BUG in binutils-2.9.1/ld on m88k-motorola-sysv3

BUG in binutils-2.9.1/ld on m88k-motorola-sysv3

[Manfred Hollstein]

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 >

Re: BUG in binutils-2.9.1/ld on m88k-motorola-sysv3

[Ian Lance Taylor]

   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

Re: BUG in binutils-2.9.1/ld on m88k-motorola-sysv3

[Manfred Hollstein]

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)