RFC: gdbtk/TODO file

RFC: gdbtk/TODO file

[Fernando Nasser]

I have been asking you for suggestions and collecting things to 
create a TODO file for Insight.  I would like to have an initial
version in the repository to make it easier for people to contribute
with ideas and, hopefully, implement/fix some things during one of
these cold winter days ;-)

The list is far from complete.  I still have several emails to review
but I thought it would be better to have something to start up.

Please do not worry too much about the "bugs" part.  The correct source for
bugs is the Gnats bug repository.  This section here is to contain bugs that
are extremely difficult to fix and will incur in major code cleanups or
even in architectural changes.  I filled it with some bugs I collected from
the archived e-mail messages I was reading so they don't get lost.  I will
move the ones that should be in the Gnats database and leave only the ones
that fulfill the above criteria later. 

If you think there is a major missing feature, architectural improvement or
have suggestions to improve the TODO file please let me know.

Thanks to all the Insight lovers (and haters) who helped collect this list.

Fernando


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


TODO:

If you find inaccuracies in this list, please send mail to
insight@sourceware.cygnus.com.  If you would like to work on any
of these, you should consider sending mail to the same address, to
find out whether anyone else is working on it.

                New Features and Enhancements
                =============================

Display of the target program output.  Perhaps use the XTerm hack created
by Tom.

--

"Disassembly from Memory" Window. Perhaps as a pane in place of the source
code one.

--

Register Window capable of handling large number of registers, typed
registers, registers organized in groups that can be shown/hidden and
that provide for better screen organization.

--

Per-project preferences so that one can have a preferred target settings
for each project (and environment variable and the current directory would
be searched for the project preference file -- global preferences would
still come from the user's home directory).

--

Reactivate the "Use this target?" confirmation box.  Do it independently of
the above?

--

Add option to activate the Source Window from the signal popup box when
the inferior program is signaled.

                     Code Cleanups
                     =============

Reorganize the Source Memory code.

--

Clean up the class hierarchy.

--

Migrate to Tcl/Tk 8.2

--

Try BLT tree as an alternative to the Tix Tree, so we can drop Tix altogether.

--

Optional use of installed Tcl/Tk (keeping it available on the distribution)

--

Fix/revamp the gdbtk testsuite.

                 Architectural Improvements
                 ==========================

Decouple the GUI from gdb, running them as separate processes.

--

Separate the Tcl part from the Tk part to facilitate scripting.

                        Bug Fixes
                        =========

Fix Source Window so that Key shortcuts work (may not be possible without
rewriting).

--

Fix info popup annoyances (like trying to show a large array without even
adding line breaks and showing up over right click menus).

--

Fix command window command line recall that misses the arguments of
commands that autoincrement their arguments.

--

Fix function browser window problems.

--

Maximization of a window affects preference sizing but forgets that maximized
state was set.

--

Taskbar "always on top" hides function combo box.

Re: RFC: gdbtk/TODO file

[Mo DeJong]

On Thu, 5 Oct 2000, Fernando Nasser wrote:

> I have been asking you for suggestions and collecting things to 
> create a TODO file for Insight. 

...

> TODO:

I would add:

1) Generic way to set a BP at a given line or function.

Add a entry widget to the breakpoints dialog perhaps?

2) Improved ability to attach to a given process.
Right now, the process listing code "exec ps -ef"
is totally broken on most platforms.

> If you find inaccuracies in this list, please send mail to
> insight@sourceware.cygnus.com.  If you would like to work on any
> of these, you should consider sending mail to the same address, to
> find out whether anyone else is working on it.
> 
>                 New Features and Enhancements
>                 =============================
> 
> Display of the target program output.  Perhaps use the XTerm hack created
> by Tom.

It would also be nice if insight (well gdb actually) could be fixed
so that it did not freeze up when run as a background process.
This is a bug but it is also a major "gdb" thing that might
require a lot of work to fix.

> Migrate to Tcl/Tk 8.2

That should be Tcl/Tk 8.3.2 now.

> Fix/revamp the gdbtk testsuite.

I am currently working on a GUI app testing system for
Source-Navigator. It might be a good idea to use
something like it for Insight too. Still, this
is something that will not be "ready" until
the next GnuPro release.

Mo DeJong
Red Hat Inc

Re: RFC: gdbtk/TODO file

[Fernando Nasser]

Mo DeJong wrote:
> 
> On Thu, 5 Oct 2000, Fernando Nasser wrote:
> 
> > I have been asking you for suggestions and collecting things to
> > create a TODO file for Insight.
> 
> ...
> 
> > TODO:
> 
> I would add:
> 
> 1) Generic way to set a BP at a given line or function.
> 

Yes, I forgot that one.  I also forgot hardware breakpoints and watchpoints.
Thanks for reminding me.  I will add them to the list.

> Add a entry widget to the breakpoints dialog perhaps?
> 

It is a possibility.


> 2) Improved ability to attach to a given process.
> Right now, the process listing code "exec ps -ef"
> is totally broken on most platforms.
> 

Thanks.  This one goes to the BUGS section.




> >                 New Features and Enhancements
> >                 =============================
> >
> > Display of the target program output.  Perhaps use the XTerm hack created
> > by Tom.
> 
> It would also be nice if insight (well gdb actually) could be fixed
> so that it did not freeze up when run as a background process.
> This is a bug but it is also a major "gdb" thing that might
> require a lot of work to fix.
> 

I am not sure if I understood this one right.  I will phone you for
more details.



> > Migrate to Tcl/Tk 8.2
> 
> That should be Tcl/Tk 8.3.2 now.
> 

That's right.


> > Fix/revamp the gdbtk testsuite.
> 
> I am currently working on a GUI app testing system for
> Source-Navigator. It might be a good idea to use
> something like it for Insight too. Still, this
> is something that will not be "ready" until
> the next GnuPro release.
> 

That is a good idea.  I would like to know more about it.



Thanks a lot (again) for your comments Mo.

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

Re: RFC: gdbtk/TODO file

[Duane Ellis]

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.

   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.

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

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)

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.

-Duane.

Re: RFC: gdbtk/TODO file

[Fernando Nasser]

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

Re: RFC: gdbtk/TODO file

[Duane Ellis]

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.

Re: RFC: gdbtk/TODO file

[Fernando Nasser]

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

Re: RFC: gdbtk/TODO file

[Keith Seitz]

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

FYI: I have used this several times on various toolchains, and it works
reasonably well. In fact, I cannot think of anything wrong with using
assembly source files with gdbtk. (Except maybe some of the
recompilation problems I've been trying to fix at various time!)

Keith

Re: RFC: gdbtk/TODO file

[Fernando Nasser]

Keith Seitz wrote:
> 
> Fernando Nasser wrote:
> >
> >
> > Right.  It is in my list of things to do try the gas -stabs option and see how
> > Insight behaves.
> 
> FYI: I have used this several times on various toolchains, and it works
> reasonably well. In fact, I cannot think of anything wrong with using
> assembly source files with gdbtk. (Except maybe some of the
> recompilation problems I've been trying to fix at various time!)
> 

That is what I would expect.  It doesn't matter for the Tcl code what is
the source language as long as the function addresses and line number debug
information is accurate.

Thanks Keith.

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

Re: RFC: gdbtk/TODO file

[Duane Ellis]

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

keith> I have used this several times on various toolchains, and it works
       reasonably well. 

Sigh... I wish I could use gas.... in our target, the assembler and
the linker perform additional optimization passes that GAS is unable
to do, hence we use our own. Maybe we should look at adding this
feature...

-Duane.