TODO list (REPOST)

TODO list (REPOST)

[Fernando Nasser]

If you find inaccuracies in this list, please send mail to
insight@sources.redhat.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.

--

Support for inserting breakpoints at arbitrary locations, perhaps adding an
entry widget to the breakpoints window.

--

Support for hardware breakpoints and watchpoints (will need fixes in gdb).

--

"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 users'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.3.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 the gdbtk testsuite.

--

Enhance the test harness, perhaps migrating to the new SourceNavigator testing
system.

                 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 process attach, specially the process listing code.

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

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

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

Re: TODO list (REPOST)

[Mo DeJong]

On Tue, 10 Oct 2000, Fernando Nasser wrote:

(Bunch of stuff about what to fix in insight)


With all this talk of "fixing" insight, I thought I
would bring up the old name issue again. The #1
question people have when starting out with
insight is "how do I run it?". People automatically
assume that the name of the executable is insight.

Lets just change the name of the executable to
insight, it is the right thing to do. This
also gets around the problem of typing % gdb
and getting insight when you expected to get
the cmd line gdb from the distro.

Here is my patch to implement the change
(minus the patch for configure itself).

Ok to check in?

Mo DeJong
Red Hat Inc

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.702
diff -u -r1.702 ChangeLog
--- ChangeLog	2000/10/10 05:17:25	1.702
+++ ChangeLog	2000/10/11 06:12:33
@@ -1,3 +1,11 @@
+2000-10-10  Mo DeJong  <mdejong@redhat.com>
+
+	* Makefile.in: Add GDB variable, it will be set to
+	gdb or insight, depending on what mode is used.
+	* configure: Regen.
+	* configure.in: Add GDB variable, pass it to Makefile.in.
+	* gdbtk/README.GDBTK: Fixed minor little typo.
+
 2000-10-09  Kevin Buettner  <kevinb@redhat.com>
 
 	* remote-nindy.c (non_dle, nindy_xfer_inferior_memory): Protoize.
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.44
diff -u -r1.44 Makefile.in
--- Makefile.in	2000/10/08 22:31:22	1.44
+++ Makefile.in	2000/10/11 06:12:35
@@ -62,6 +62,9 @@
 WINDRES = @WINDRES@
 MIG = @MIG@
 
+# Name of gdb executable, set to "insight" in gdbtk mode
+GDB = @GDB@
+
 # Flags that describe where you can find the termcap library.
 # This can be overridden in the host Makefile fragment file.
 TERMCAP = @TERM_LIB@
@@ -669,7 +672,7 @@
 .c.o:
 	$(CC) -c $(INTERNAL_CFLAGS) $<
 
-all: gdb$(EXEEXT) $(CONFIG_ALL)
+all: $(GDB)$(EXEEXT) $(CONFIG_ALL)
 	@$(MAKE) $(FLAGS_TO_PASS) DO=all "DODIRS=`echo $(SUBDIRS) | sed 
's/testsuite//'`" subdir_do
 
 installcheck:
@@ -700,23 +703,23 @@
 install: all install-only
 install-only: $(CONFIG_INSTALL)
 	transformed_name=`t='$(program_transform_name)'; \
-			  echo gdb | sed -e $$t` ; \
+			  echo $(GDB) | sed -e $$t` ; \
 		if test "x$$transformed_name" = x; then \
-		  transformed_name=gdb ; \
+		  transformed_name=$(GDB) ; \
 		else \
 		  true ; \
 		fi ; \
 		$(srcdir)/../mkinstalldirs $(bindir) ; \
-		$(INSTALL_PROGRAM) gdb$(EXEEXT) 
$(bindir)/$$transformed_name$(EXEEXT) ; \
+		$(INSTALL_PROGRAM) $(GDB)$(EXEEXT) 
$(bindir)/$$transformed_name$(EXEEXT) ; \
 		$(srcdir)/../mkinstalldirs $(man1dir) ; \
 		$(INSTALL_DATA) $(srcdir)/gdb.1 $(man1dir)/$$transformed_name.1
 	@$(MAKE) DO=install "DODIRS=$(SUBDIRS)" $(FLAGS_TO_PASS) 
subdir_do 
 
 uninstall: force $(CONFIG_UNINSTALL)
 	transformed_name=`t='$(program_transform_name)'; \
-			  echo gdb | sed -e $$t` ; \
+			  echo $(GDB) | sed -e $$t` ; \
 		if test "x$$transformed_name" = x; then \
-		  transformed_name=gdb ; \
+		  transformed_name=$(GDB) ; \
 		else \
 		  true ; \
 		fi ; \
@@ -783,9 +786,9 @@
 init.o: init.c $(defs_h) $(call_cmds_h)
 
 # Removing the old gdb first works better if it is running, at least on 
SunOS.
-gdb$(EXEEXT): main.o libgdb.a $(ADD_DEPS) $(CDEPS) $(TDEPLIBS)
-	rm -f gdb$(EXEEXT)
-	$(HLDENV) $(CC_LD) $(INTERNAL_LDFLAGS) $(WIN32LDAPP) -o 
gdb$(EXEEXT) main.o libgdb.a $(TDEPLIBS) $(TUI_LIBRARY) $(CLIBS) $(LOADLIBES)
+$(GDB)$(EXEEXT): main.o libgdb.a $(ADD_DEPS) $(CDEPS) $(TDEPLIBS)
+	rm -f $(GDB)$(EXEEXT)
+	$(HLDENV) $(CC_LD) $(INTERNAL_LDFLAGS) $(WIN32LDAPP) -o 
$(GDB)$(EXEEXT) main.o libgdb.a $(TDEPLIBS) $(TUI_LIBRARY) $(CLIBS) 
$(LOADLIBES)
 
 nlm:	force
 	rootme=`pwd`; export rootme; $(MAKE) $(TARGET_FLAGS_TO_PASS) 
DO=all DODIRS=nlm subdir_do
@@ -838,7 +841,7 @@
 # in another process.
 gdb1$(EXEEXT): gdb$(EXEEXT)
 	rm -f gdb1$(EXEEXT)
-	cp gdb$(EXEEXT) gdb1$(EXEEXT)
+	cp $(GDB)$(EXEEXT) gdb1$(EXEEXT)
 
 # FIXME. These are not generated by "make depend" because they only are 
there
 # for some machines.
@@ -883,7 +886,7 @@
 	@$(MAKE) $(FLAGS_TO_PASS) DO=clean "DODIRS=$(SUBDIRS)" subdir_do 
 	rm -f *.o *.a $(ADD_FILES) *~ init.c-tmp init.l-tmp
 	rm -f init.c version.c
-	rm -f gdb$(EXEEXT) core make.log
+	rm -f $(GDB)$(EXEEXT) core make.log
 	rm -f gdb[0-9]$(EXEEXT)
 
 # This used to depend on c-exp.tab.c m2-exp.tab.c TAGS
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.44
diff -u -r1.44 configure.in
--- configure.in	2000/09/11 17:57:07	1.44
+++ configure.in	2000/10/11 06:12:35
@@ -759,9 +759,13 @@
 
 configdir="unix"
 
+# This will be set to "insight" if using gdbtk
+GDB=gdb
+
 GDBTKLIBS=
 if test "${enable_gdbtk}" = "yes"; then
 
+    GDB=insight
     CY_AC_PATH_TCLCONFIG
     if test -z "${no_tcl}"; then
 	CY_AC_LOAD_TCLCONFIG
@@ -869,6 +873,7 @@
 AC_SUBST(ITK_DEPS)
 AC_SUBST(TIXLIB)
 AC_SUBST(TIX_DEPS)
+AC_SUBST(GDB)
 AC_SUBST(GDBTKLIBS)
 AC_SUBST(GDBTK_CFLAGS)
 
Index: gdbtk/README.GDBTK
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/README.GDBTK,v
retrieving revision 1.2
diff -u -r1.2 README.GDBTK
--- README.GDBTK	2000/04/17 20:20:20	1.2
+++ README.GDBTK	2000/10/11 06:12:36
@@ -10,7 +10,7 @@
 ============
 
 GDBtk is a version of GDB that uses Tcl/Tk to implement a graphical
-user inter-face.  It is a fully integrated GUI, not a separate
+user interface.  It is a fully integrated GUI, not a separate
 front-end program.  The interface consists of several seperate
 windows, which use standard elements like buttons, scrollbars, entry
 boxes and such to create a fairly easy to use interface.  Each window

Re: TODO list (REPOST)

[Grant Edwards]

On Tue, Oct 10, 2000 at 11:15:40PM -0700, Mo DeJong wrote:

> With all this talk of "fixing" insight, I thought I
> would bring up the old name issue again. The #1
> question people have when starting out with
> insight is "how do I run it?". People automatically
> assume that the name of the executable is insight.
> 
> Lets just change the name of the executable to
> insight, it is the right thing to do. This
> also gets around the problem of typing % gdb
> and getting insight when you expected to get
> the cmd line gdb from the distro.

My preference would be for it to come up in command-line mode
if invoked as *gdb, and GUI mode if invoked as *insight.

-- 
Grant Edwards
grante@visi.com

Re: TODO list (REPOST)

[Fernando Nasser]

Grant Edwards wrote:
> 
> On Tue, Oct 10, 2000 at 11:15:40PM -0700, Mo DeJong wrote:
> 
> > With all this talk of "fixing" insight, I thought I
> > would bring up the old name issue again. The #1
> > question people have when starting out with
> > insight is "how do I run it?". People automatically
> > assume that the name of the executable is insight.
> >
> > Lets just change the name of the executable to
> > insight, it is the right thing to do. This
> > also gets around the problem of typing % gdb
> > and getting insight when you expected to get
> > the cmd line gdb from the distro.
> 
> My preference would be for it to come up in command-line mode
> if invoked as *gdb, and GUI mode if invoked as *insight.
> 

Yes, that is the idea.  A modification in Mo's patch that will default to -w
if the name contains "insight" and to -nw otherwise would do that.

However....

We would have to make sure proper credits are made to GDB, the GNU project, FSF etc.
Insight is just a GUI, it does nothing without gdb, which was a program originally 
written by Richard Stallman and made public under the GPL.  We have no right to
rename it and take away the credits.

So, I propose we make very visible in the GUI the words "GNU gdb", add to the splash
screen (same as About) which would be on by default the proper credits and disclaimers
(as printed when gdb starts).  After we do this we can start the gdb GUI by typing
"insight" with no guilty. 

This brings a question: Where do I add the "GNU gdb version N.NN..."? 

Somewhere in the Source Window, I believe.  Do I make it the window title?

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

Re: TODO list (REPOST)

[Tom Tromey]

>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:

Fernando> Yes, that is the idea.  A modification in Mo's patch that
Fernando> will default to -w if the name contains "insight" and to -nw
Fernando> otherwise would do that.

The GNU Coding Standards ask that the program's behavior not depend on
the name of the program:

       Please don't make the behavior of a utility depend on the name used
    to invoke it.  It is useful sometimes to make a link to a utility with
    a different name, and that should not change what it does.

Tom

Re: TODO list (REPOST)

[Grant Edwards]

> Fernando> Yes, that is the idea.  A modification in Mo's patch that
> Fernando> will default to -w if the name contains "insight" and to -nw
> Fernando> otherwise would do that.
> 
> The GNU Coding Standards ask that the program's behavior not depend on
> the name of the program:
> 
>        Please don't make the behavior of a utility depend on the name used
>     to invoke it.  It is useful sometimes to make a link to a utility with
>     a different name, and that should not change what it does.

Eh?  Aren't there are other gnu utilities that do different
things depending on the name used to invoke them? gzip, gunzip,
zcat, for example?

-- 
Grant Edwards
grante@visi.com

Re: TODO list (REPOST)

[Mo DeJong]

On 11 Oct 2000, Tom Tromey wrote:

> >>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
> 
> Fernando> Yes, that is the idea.  A modification in Mo's patch that
> Fernando> will default to -w if the name contains "insight" and to -nw
> Fernando> otherwise would do that.
> 
> The GNU Coding Standards ask that the program's behavior not depend on
> the name of the program:
> 
>        Please don't make the behavior of a utility depend on the name used
>     to invoke it.  It is useful sometimes to make a link to a utility with
>     a different name, and that should not change what it does.
> 
> Tom

If we just call it "insight", then there will be no problem with hiding 
the regular command line gdb when the user runs gdb from the PATH.
I would say this alone is reason enough to call it insight
and nothing else. Does anyone have any good reasons for
calling it gdb? I am all for giving credit to the Gnu
project, I just think we have confused people long
enough by calling it gdb.

Mo DeJong
Red Hat Inc

Re: TODO list (REPOST)

[Mo DeJong]

Here is another little breakpoint related thing that I noticed.

You can set or remove a breakpoint in the src window by clicking
on the left of the line.

Problem is, there does not seem to be any way to disable a
breakpoint. I can open up the breakpoint window and right
click on a BP, that gives me a popup with a disable breakpoint
window. Why do I not have this same option when I right click
on a breakpoint out in the main source window? In the
source window, a right click brings up these options:

- Continue to Here
- Jump to Here
- Delete Breakpoint
- Jump to Here
- Jump to Here

Why are there two "Jump to Here" options? Also, has anyone
else noticed that the color of the menu highlight gets all
wonky when you move the mouse down in the window? Whats
up with that?

thanks
Mo DeJong
Red Hat Inc

Re: TODO list (REPOST)

[Fernando Nasser]

Mo DeJong wrote:
> 
> Here is another little breakpoint related thing that I noticed.
> 
> You can set or remove a breakpoint in the src window by clicking
> on the left of the line.
> 
> Problem is, there does not seem to be any way to disable a
> breakpoint. I can open up the breakpoint window and right
> click on a BP, that gives me a popup with a disable breakpoint
> window. Why do I not have this same option when I right click
> on a breakpoint out in the main source window? 
> 

Yes we should.  But we would need a hollow square mark to sign that 
there is a disable breakpoint in that location.  In the Breakpoint
window, if you disable a breakpoint you still see it and can go there
and enable it.  We would need an Enable option to replace the Disable
option for the disabled breakpoints in the Source window.

It is a valid enhancement request though.

> In the
> source window, a right click brings up these options:
> 
> - Continue to Here
> - Jump to Here
> - Delete Breakpoint
> - Jump to Here
> - Jump to Here
> 
> Why are there two "Jump to Here" options? 

That would probably be my fault (as I added Jump to Here).
However, I don't see this in here.  I would need to know under
which conditions this happens.

The code in there was making reference to menu items by literal numbers.
I fixed it in a few places to use a variable but I may have missed one. 


> Also, has anyone
> else noticed that the color of the menu highlight gets all
> wonky when you move the mouse down in the window? Whats
> up with that?
> 

Yes, I believe it is a feature. It is too regular to be a bug.
I just don't know the meaning of the colors nor who added this effect.


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

Re: TODO list (REPOST)

[Mo DeJong]

On Wed, 11 Oct 2000, Fernando Nasser wrote:

> > Here is another little breakpoint related thing that I noticed.
> > 
> > You can set or remove a breakpoint in the src window by clicking
> > on the left of the line.
> > 
> > Problem is, there does not seem to be any way to disable a
> > breakpoint. I can open up the breakpoint window and right
> > click on a BP, that gives me a popup with a disable breakpoint
> > window. Why do I not have this same option when I right click
> > on a breakpoint out in the main source window? 
> > 
> 
> Yes we should.  But we would need a hollow square mark to sign that 
> there is a disable breakpoint in that location.  In the Breakpoint
> window, if you disable a breakpoint you still see it and can go there
> and enable it.  We would need an Enable option to replace the Disable
> option for the disabled breakpoints in the Source window.

That is not a problem. When you disable a BP the square
turns black instead of red (or course grey might be better).
There is already support for this, we just need a menu
option to use it.
 
> > In the
> > source window, a right click brings up these options:
> > 
> > - Continue to Here
> > - Jump to Here
> > - Delete Breakpoint
> > - Jump to Here
> > - Jump to Here
> > 
> > Why are there two "Jump to Here" options? 
> 
> That would probably be my fault (as I added Jump to Here).
> However, I don't see this in here.  I would need to know under
> which conditions this happens.

Just set a BP by clicking to the left of the line, then right
click on the red BP square, presto!

Mo DeJong
Red Hat Inc

RMS in the press [Was: TODO list (REPOST)]

[Fernando Nasser]

From the Toronto Star first page of the "@Biz" section
(I don't know which new agency originated the article though):

"Reclusive Richard Stallman pioneered free software, but gets little credit"

It bashes Red Hat for omitting RMS from the "major milestones in open source"
in our web pages.

The article ends up with RMS claiming for people to say GNU/Linux.




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

Re: TODO list (REPOST)

[Fernando Nasser]

Mo DeJong wrote:
> 
> That is not a problem. When you disable a BP the square
> turns black instead of red (or course grey might be better).
> There is already support for this, we just need a menu
> option to use it.
> 

OK, so I will add it soon.


> > > In the
> > > source window, a right click brings up these options:
> > >
> > > - Continue to Here
> > > - Jump to Here
> > > - Delete Breakpoint
> > > - Jump to Here
> > > - Jump to Here
> > >
> > > Why are there two "Jump to Here" options?
> >
> > That would probably be my fault (as I added Jump to Here).
> > However, I don't see this in here.  I would need to know under
> > which conditions this happens.
> 
> Just set a BP by clicking to the left of the line, then right
> click on the red BP square, presto!
> 

I got it now. It happens when we switch to the Disable Breakpoint option.
It will be fixed momentarily.

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

Fix to Breakpoint right-click menu bug [Was: TODO list (REPOST)]

[Fernando Nasser]

Mo DeJong wrote:
> 
> > > In the
> > > source window, a right click brings up these options:
> > >
> > > - Continue to Here
> > > - Jump to Here
> > > - Delete Breakpoint
> > > - Jump to Here
> > > - Jump to Here
> > >
> > > Why are there two "Jump to Here" options?
> >
> > That would probably be my fault (as I added Jump to Here).
> > However, I don't see this in here.  I would need to know under
> > which conditions this happens.
> 
> Just set a BP by clicking to the left of the line, then right
> click on the red BP square, presto!
> 

Here is the fix.  It was me and my cut-and-paste mistakes (I get interrupted
all the time and sometines go back in the wrong context :-)

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



Index: srctextwin.itb
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/srctextwin.itb,v
retrieving revision 1.10
diff -c -p -r1.10 srctextwin.itb
*** srctextwin.itb	2000/10/04 20:35:32	1.10
--- srctextwin.itb	2000/10/11 22:30:09
*************** body SrcTextWin::build_popups {} {
*** 239,245 ****
      if {[pref get gdb/control_target]} {
        
        addPopup tp "Continue to Here" "$this continue_to_here" green 0 0
!       addPopup bp "Jump to Here" "$this jump_to_here" {} 0 0
        #	$popups(tp) add separator    
  
        # Currently you cannot set a tracepoint and a breakpoint at the same line...
--- 239,245 ----
      if {[pref get gdb/control_target]} {
        
        addPopup tp "Continue to Here" "$this continue_to_here" green 0 0
!       addPopup tp "Jump to Here" "$this jump_to_here" {} 0 0
        #	$popups(tp) add separator    
  
        # Currently you cannot set a tracepoint and a breakpoint at the same line...
*************** body SrcTextWin::build_popups {} {
*** 272,278 ****
      if {!$Browsing && [pref get gdb/control_target]} {
        addPopup bp_and_tp "Continue to Here" "$this continue_to_here" \
  	green 0 0
!       addPopup bp "Jump to Here" "$this jump_to_here" \
  	green 0 0
        $popups(bp_and_tp) add separator    
      }
--- 272,278 ----
      if {!$Browsing && [pref get gdb/control_target]} {
        addPopup bp_and_tp "Continue to Here" "$this continue_to_here" \
  	green 0 0
!       addPopup bp_and_tp "Jump to Here" "$this jump_to_here" \
  	green 0 0
        $popups(bp_and_tp) add separator    
      }