Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!AI.MIT.EDU!kingdon
From: kingdon@AI.MIT.EDU (Jim Kingdon)
Newsgroups: gnu.gdb.bug
Subject: gdb 'bugs'  (enhancement requests?) and a patch...
Message-ID: <9002240839.AA21345@pogo>
Date: 24 Feb 90 08:39:07 GMT
References: <9002222313.AA11440@curley.osf.org.osf.org>
Sender: root@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 31


    As much as I detest the COFF debug format, I believe that a
    standardized debug format is useful

Well, let me point out that GNU has a standardized debug format: BSD
a.out executables with dbx symbols.  While we have agreed in some
cases (e.g. GDB) to merge COFF support into GNU software, COFF support
isn't important to us and we put little effort into maintaining it.
On systems with COFF kernels, you can use BSD executables with COFF
encapsulation.

Some hybrid which uses COFF, but with debug tables in a separate
section or some such, might be possible.  The advantage would be you
can use the system binutils and assembler.  But if you port (if not
done already) GNU binutils and assembler to your machine, then you
have source to the utilities, can fix them if broken, and also get
whatever level of support is provided by the FSF and whoever else is
using the GNU utilities.

So getting encapsulation working might involve some work such as
porting the GNU utilities (should be easy except the assembler, which
shouldn't be terrible), but on the other hand, getting COFF support in
GDB working well (and/or maintaining it as GDB and/or COFF evolve) is
also work.

I will admit that dbx symbols could be better documented.  dbxread.c
in GDB and dbxout.c in GCC are (as source code goes anyway) reasonably
legible, however.

Object file and debug formats have both political and technical
aspects.  I think GNU/BSD format beats COFF on both.