Re: RFC: gdbtk/TODO file

[Duane Ellis <duane_ellis@franklin.com>]

duane>  1) Better support for assembly language debugging.

fernado> That one is hard.  The problem is that we need a start point
	 for disassembly in several architectures...

You are right. This problem will have to be solved in the more general
case {see below}. It's expecially true of cpus with variable length
instructions. (ie: 99.9% of all CPUS out there). You don't know if you
are disassembling an opcode or an immediate operand contained in the
instruction stream, or random data. Most disassemblers, when they get
lost start inserting 'db' statements for invalid data.

fernado> This is possible.  Disassembly from memory at the PC as an
	 alternative view is in my wish list.

How about making this window some what "operator controled", in that
the operator could specify a the start/stop address to disassemble
from. You could use the PC and PC+500 as initial starting points.

In any case, this puts the onus on the operator for choosing a known
good starting point. Manytimes, I have choosen a starting address only
to find it is wrong. I then go back another 10 to 15 bytes and try
again, normally the disassmebler is albe to re-sync it self.

There are other problems, for instance in some architectures you may
well insert "switch statement" jump tables in the middle of the
function, where others may place this at the end of the function.

fernado> Another point is that we want to be able to mix it with
	 source code knowledge (for instance SourceNavigator's) to be
	 able to Code/Build/Debug in the same environment.  A good
	 reason to keep the file and function/method units.

Ok then, maybe the ablity to treat ASSEMBLY as source code when it
really is the source code. You only need to disable mouseover stuff in
the assembly view mode.

This comes down to knowledge of what is the minimally required set of
stabs/debug records you need to make quazi assembly source level
debugging work. Other problems with this approach mean dealing with
traditional macro expansion, vrs C preprocessor type expansion.

-Duane.