gdb and coff symbols.

["Dan Haynes" <haynes at montanadsl dot net>]

I spent several days tracking this one down. I don't know if it is a bug as much as it is a change in behaviour relative to older versions of gdb and/or ld.

We had been using GNUPro 98r2 to build a very large m68k-coff project. We moved it to linux and built our own m68k-coff toolchain (gcc 2.95.3, binutils 2.9.1 and newlib 1.8.2)

Everything went fairly smoothly, except that gdb was unable to load the resulting .coff files. It always gave the following error:

	$ m68k-coff-gdb test.coff
	GNU gdb 5.1
	Copyright 2001 Free Software Foundation, Inc.
	GDB is free software, covered by the GNU General Public License, and you are
	welcome to change it and/or distribute copies of it under certain conditions.
	Type "show copying" to see the conditions.
	There is absolutely no warranty for GDB.  Type "show warranty" for details.
	This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-coff"...../../gdb-	5.1/gdb/coffread.c:955: gdb-internal-error: sect_index_data not initialized
	An internal GDB error was detected.  This may make further
	debugging unreliable.  Continue this debugging session? (y or n) y

After *much* searching around I finally discovered that the problem was the lack of section definitions for .stab and .stabstr. It failed when I didn't specify to the linker:

	.stab 0 (NOLOAD) : { *(.stab) }
	.stabstr 0 (NOLOAD) : { *(.stabstr) }

The reason that I think it's a gdb error is that all the other utilities handled the file just fine - objdump, nm, objcopy were able to examine, read, and convert the file with no problems. An in-house COFF manipulation tool found no problems with the file either. 

gdb V5.1 and V5.1.1 both failed with the same message on startup.

Again, I don't know if it's a bug, or simply an incompatability. 

Anyway, I hope this bit of info might save folks more than a few hours of hair pulling and head banging when converting older projects.

   Dan Haynes