Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!osf.org!meissner
From: meissner@osf.org
Newsgroups: gnu.gdb.bug
Subject: gdb 'bugs'  (enhancement requests?) and a patch...
Message-ID: <9003012029.AA22282@curley.osf.org.osf.org>
Date: 1 Mar 90 20:29:37 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 48

| From: rms@AI.MIT.EDU
| Newsgroups: gnu.gdb.bug
| Date: 28 Feb 90 19:58:15 GMT
| Distribution: gnu
| Organization: GNUs Not Usenet
| 
| The BSD object file format has some deficiencies, so we're considering
| switching to another format for the GNU system.  However, one aspect that
| we are not considering changing is the debugger information.  That is not
| where the problems are, and leaving it alone would save lots of work.
| So ELF won't be a good candidate.

I don't know about the lack of problems with the BSD debug format.
Yes COFF is certainly crippled, but current stabs are only marginly
better.  The problem is that both formats are living back in the mid
70's when UNIX compilers did little optimization (other than peephole
optimizations).  Some of the problems that I have with either format
(though they can be solved with extensions, and such):

    1)	No support for variable lifetime information except on block
	boundaries.  GCC will allocate multiple values to the same
	registers if their lifetimes are disjoint.  This means that
	the user gets confused if s/he wants to look at a variable
	after the compiler has already put another value into the
	register.  On machines that pass arguments in registers, if
	the argument is used once, and not used again, this will mean
	that the function traceback will print bogus values.

    2)	No support for variables living in multiple places (such as
	normally on the stack, but in a register within a loop).  I
	know that GCC currently does not do this optimization, but I
	would hope that is only a temporary restriction.

    3)	No support for multiple statements on one line.  This is
	particularly bad for 'for' statements, which have three
	implicit statements, but if it's all on one line, you can only
	set a breakpoint on the initial condition, and not on the test
	(or increment) statement.

    4)	No support for keeping line numbers during code motion.  If a
	divide, say, is moved out of a loop, there is no line number
	associated with that code.

    5)	Debuggable code must have a frame pointer.  Of the RISC
	machines I familar with (MIPS and M88K), the native compilers
	routinely eliminate the frame pointer, and have extra tables
	to describe how to get the virtual frame pointer from the
	stack pointer, and where saved registers live.