Re: RFC: gdbtk/TODO file

[Fernando Nasser <fnasser@cygnus.com>]

Hi Duane, thanks for your comments.


Duane Ellis wrote:
> 
> On Thu, 5 Oct 2000, Fernando Nasser wrote:
> 
> > TODO:
> 
> I live in an embedded world; I would add:
> 
> 1) Better support for assembly language debugging.
> 
>    In mixed and assembly mode - in effect, the source window would be
>    a virtual window with no real top or bottom, and not be bound to
>    the limits of the C file you are viewing.
> 

That one is hard.  The problem is that we need a start point for disassembly
in several architectures (pure RISC being an exception as any aligned address
would do).  Gdb and the debug information only provide us function limits.

Also, with a source file being shown, what criteria would we use to go beyond 
the end (or start) of a source file?  The linker may have laid things out in
memory very arbitrarily.  Following the memory addresses and tracking things 
backwards is even worse: quite dependent on reverse searches on function and 
line number information.

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.


>    For instance, your I/O routines may be functions contained in a ROM
>    monitor (and not part of your program), and you would like to
>    assembly single step through them.
> 

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


>    Or maybe you have a library with no symbolic information but need
>    to debug anyway.
>
Same as above.

 
> 2) A way of telling the GUI to reset and reconfigure it self.
> 
>    Change the program counter to an arbitrary address.  Now tell
>    insight's source window (and all others) to fix them selves.
> 
>    ie:   (gdb)  set $pc=0x12345678
> 
>    How do I get the GUI to update it self to the new PC location?
> 
>    (Happens with simulators & rom targets when you issue a target
>    command that GDB passes through and cannot understand)
> 

I've run into this problem already.  We need to fix gdb first as it is keeping
stale information in this cases.  We have been talking about a command to do
something like flush register and memory caches in gdb.  It will be possible
to add a Refresh thing to the GUI after that.

I forgot to add this to the TODO file though.  Thanks for bringing it up.



> 3) The Ability to run without a target, and no symbols.
>    [this is in a ROM or simulator world]
> 
>    Load and attach to the target (simulator or rom monitor) issue
>    various "target/simulator" commands that make the program load into
>    memory.  (that GDB does not know about, nor can you explain to GDB
>    in any way)
> 
>    GDB can't seem to run unless it has loaded a file. That's not
>    always required.
> 

Funny, I can run without load.  

There are some subtle differences between some variations of remote targets.
Which one specifically are you using?


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