From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@cygnus.com>
To: manfred@s-direktnet.de, Manfred.Hollstein@ks.sel.alcatel.de
Cc: bfd@cygnus.com, gas2@cygnus.com, bug-gnu-utils@gnu.org
Subject: Re: BUG in binutils-2.9.1/ld on m88k-motorola-sysv3
Date: Tue, 07 Jul 1998 08:27:00 -0000
Message-id: <199807071527.LAA14464@subrogation.cygnus.com>
References: <13729.64373.444444.251863@slsvhmt>
X-SW-Source: 1998/msg00194.html

   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