Re: RFC: gdbtk/TODO file

[Fernando Nasser <fnasser@cygnus.com>]

Duane Ellis wrote:
> 
> 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.
> 
Absolutely.  Lets make the start address editable.

My idea is that it switches to MEMORY mode when we cannot get source info and
we start the disassembler at the PC.  But having the satrt address editable is
a nice feature.  Thanks for the suggestion.


> 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.
> 
Yes, that is how I so my asm hacking ;-)



> 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.
>
True.  But without debugging info there is little we can do.  Anyway. Insight
used gdb disassembly which is not even gdb's, but binutils.  The smarter that
one is the smarter we can be, no more than that.
 
> 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. 

Right.  It is in my list of things to do try the gas -stabs option and see how
Insight behaves.

> You only need to disable mouseover stuff in
> the assembly view mode.
> 
Someone mentioned this some time ago.  I wish it had been entered in the bug database...


> 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.
> 

See above.


Thanks for the comments/suggestions.

Regards,
Fernando

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9