GDB TUI doesn't build

GDB TUI doesn't build

[Richard Shih-Ping Chan]

Hi - looking at the 2001-01-08 CVS, GDB TUI doesn't build
[Does TUI actually work?] Anyway find_line_pc in several
gdb/tui/tui*.c files doesn't agree with the actual definition in gdb/.

BTW configure on i686-linux also doesn't seem to define USG and 
HAVE_TERM_H which are necessary for tui.o to be built.

Cheers.

-- 

Chan Shih-Ping (Richard) <cshihpin@dso.org.sg>
DSO National Laboratories
20 Science Park Drive
Singapore 118230
From fnasser@cygnus.com Mon Jan 08 07:26:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Richard Shih-Ping Chan <cshihpin@dso.org.sg>
Cc: GDB <gdb@sources.redhat.com>, Kevin Buettner <kevinb@redhat.com>
Subject: Re: GDB TUI doesn't build
Date: Mon, 08 Jan 2001 07:26:00 -0000
Message-id: <3A59DBFD.19EED398@cygnus.com>
References: <20010108183654.B467@cshihpin.isl.dso>
X-SW-Source: 2001-01/msg00014.html
Content-length: 885

Richard Shih-Ping Chan wrote:
> 
> Hi - looking at the 2001-01-08 CVS, GDB TUI doesn't build
> [Does TUI actually work?] Anyway find_line_pc in several
> gdb/tui/tui*.c files doesn't agree with the actual definition in gdb/.
> 
> BTW configure on i686-linux also doesn't seem to define USG and
> HAVE_TERM_H which are necessary for tui.o to be built.
> 

The maintainer of the TUI is HP (from the gdb/MAINTAINERS file):

tui                     Technical Contact Point wdb@cup.hp.com

They've contributed it some time ago.

It seems that the person who was maintaining it is not around anymore.
Maybe it got a little bit outdated.

Perhaps you would be interested in trying to fix it?

Or maybe you can run the GDB GUI (Insight) instead.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From charlet@ACT-Europe.FR Mon Jan 08 07:56:00 2001
From: Arnaud Charlet <charlet@ACT-Europe.FR>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Richard Shih-Ping Chan <cshihpin@dso.org.sg>, GDB <gdb@sources.redhat.com>, Kevin Buettner <kevinb@redhat.com>
Subject: Re: GDB TUI doesn't build
Date: Mon, 08 Jan 2001 07:56:00 -0000
Message-id: <20010108165633.F26870@dublin.int.act-europe.fr>
References: <20010108183654.B467@cshihpin.isl.dso> <3A59DBFD.19EED398@cygnus.com>
X-SW-Source: 2001-01/msg00015.html
Content-length: 236

> Or maybe you can run the GDB GUI (Insight) instead.

Or use one of the other available GUI front-ends for GDB, including
GVD and DDD.

GVD home page: http://libre.act-europe.fr/gvd
DDD home page: http://www.gnu.org/software/ddd

Arno
From pedwards@disaster.jaj.com Mon Jan 08 17:55:00 2001
From: Phil Edwards <pedwards@disaster.jaj.com>
To: gdb@sources.redhat.com
Subject: fwd:  fixing some FIXMEs
Date: Mon, 08 Jan 2001 17:55:00 -0000
Message-id: <20010108210432.A32378@disaster.jaj.com>
X-SW-Source: 2001-01/msg00016.html
Content-length: 2107

I ran into these two FIXMEs in the top-level configury.  The one which
tests the host is moved into the per-host section, and the one which sets
up GDB_TK is moved into the per-target section.

Opinions?  Comments?  This would need to be committed in both the src and
gcc repositories, I believe, but since the patch deals with GDB/Insight,
it was suggested that it be hashed over here first.


Index: configure
===================================================================
RCS file: /cvs/gcc/gcc/configure,v
retrieving revision 1.33
diff -u -3 -r1.33 configure
--- configure	2001/01/02 15:44:40	1.33
+++ configure	2001/01/09 00:21:16
@@ -1069,21 +1069,6 @@
 export CFLAGS
 export CXXFLAGS
 
-# FIXME: This should be in configure.in, not configure
-case "$host" in
-	*go32*)
-	    enable_gdbtk=no ;;
-	*msdosdjgpp*)
-	    enable_gdbtk=no ;;
-esac
-
-# FIXME: This should be in configure.in, not configure
-# Determine whether gdb needs tk/tcl or not.
-if [ "$enable_gdbtk" != "no" ]; then
-	GDB_TK="all-tcl all-tk all-itcl all-tix all-libgui"
-else
-	GDB_TK=""
-fi
 
 for subdir in . ${subdirs} ; do
 
Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.84
diff -u -3 -r1.84 configure.in
--- configure.in	2001/01/02 15:36:25	1.84
+++ configure.in	2001/01/09 00:21:16
@@ -277,6 +277,14 @@
   fi
 fi
 
+# Moved from configure.
+case "$host" in
+  *go32*)
+    enable_gdbtk=no ;;
+  *msdosdjgpp*)
+    enable_gdbtk=no ;;
+esac
+
 # We default to --with-shared on platforms where -fpic is meaningless.
 # Well, we don't yet, but we will.
 if false && [ "${host}" = "${target}" ] && [ x${enable_shared} = x ]; then
@@ -974,6 +982,14 @@
   use_gnu_as=no
   noconfigdirs="$noconfigdirs gas"
 fi
+
+# Determine whether gdb needs tk/tcl or not.  Moved from configure.
+if [ "$enable_gdbtk" != "no" ]; then
+  GDB_TK="all-tcl all-tk all-itcl all-tix all-libgui"
+else
+  GDB_TK=""
+fi
+
 
 # Figure out what language subdirectories are present.
 # Look if the user specified --enable-languages="..."; if not, use

GDB TUI doesn't build

[Andrew Cagney]

[I had several requests for this so I'm going to add it to the gdb/TODO
file].

For those that are interested, my list of TUI problems are below.

There is also a more general issue.  I know HP have an in-house version
of the TUI.  It might be easiest to replace the current public version
with HP's (even if it still doesn't build) and then start on bring it up
to scratch.

Fix TUI

     o  readline/*.h bitrot

        The TUI isn't up-to-date with
        respect to the readline currently
        bundled with GDB.  Importing a
        new readline is on the 5.1 wish
        list so this can only get worse.

        Grep for things like term_cursor_move.

        (To be honest, I don't see anyone
        importing a new readline before 5.1 is
        out)

     o  tui.c:va_catch_errors() bitrot

        This nasty piece of work used knowledge
        of the internals of GDBs error functions :-(
        Ever since those internals were cleaned
        up this code has been broken. :-(

     o  tuiWin.c:c_makeVisibleWithNewHeight() broken
        tuiLayout.c:_extractDisplayStartAddr() broken

        Both these function call find_line_pc()
        incorrectly (wrong args, wrong return value).

        I suspect this bug has always been there!
        It had been hidden because those files
        didn't include the necessary header files
        from gdb proper :-(

     o  tuiRegs() host dependant

        Not suprisingly, this isn't a very portable
        section of code.  However, I'm sure people
        could live with no regs in the short to
        medium term.

     o  defs.h: #include "tui.h" et.al.

        I'm not sure where this came from.
        It was a really bad idea.

        To get things to compile I did a nasty
        hack (Just declare what was needed and
        replace any expressions like xx->y.z()
        in GDB proper with function calls).  I
        could commit it slightly cleaned up if
        you like.

        Medium Term. the #ifdef TUI and TuiDo()
        should be changed to hooks (like GDBTK).
        The gdb-events.[hc] is there for that
        purpose (1)

     o  tui.c:_tuiReset() host dependant

        tui.c contains a lump of termio[s]
        I suspect an equivalent block of
        code can be lifted from readline.
        An equivalent readline function may
        even be available.

     o  curses.h vs ncurses.h.

        Simple portability problem.

     o  subsetCompare()

        This function is a mystery - where is it?

     o  tui-file.[hc] cleanup

        This can be significantly simplified.

     o  The code should be pacified. (-Werror -W...)

        There are plenty of #includes,
        duplicate #includes, missing function decls
        and the like.

        Some of the problems I found were through
        fixing a few of the warnings.

     o  The code should be GNUtified.

        It would be very nice to have this code
        look like the rest of GDB.  That way people
        would be more accepting of it as a true
        gdb component.

        Until it is GNUtified it is going to stick
        out like a sore thumb to the programmer.

     o  The code should be clearly copyrighted

        (FSF, with due credit to HP)

Re: GDB TUI doesn't build

[Mike Brownlow]

Andrew Cagney wrote:
> [I had several requests for this so I'm going to add it to the gdb/TODO
> file].
> 
> For those that are interested, my list of TUI problems are below.
> 
<snip things to fix>

Hi,
  I thought this would be a good opportunity to raise a question I
have about the TUI in GDB. I have recently registered my libtui as a
project on freshmeat, before I knew that my favorite debugger had
a libtui in it. I'm wondering if this would cause problems for
anybody? Should I change my lib's name? Or will it not be a big
deal? I don't want to use libtui if the plans for GDB libtui are
to release it separately or if GDB programmers dislike the idea of my
lib having the same name. Obviously GDB TUI has been around longer,
but I wanted to hear what people think about this.

  I honestly wasn't aware that a libtui existed yet, but I'm willing
to change the name for my favorite debugger. :)

  My lib is at: http://www.wsmake.org/~mike/software/libtui/

Thanks,
-- 
Mike Brownlow                        http://www.wsmake.org/~mike/
-----------------------------------------------------------------
1024D/8AA6EAFD 3861 96B3 EEA2 285C BE23  F706 3E1E EBB2 8AA6 EAFD
"Hatred stirreth up strifes: but love covereth all sins." Pr10:12

Re: GDB TUI doesn't build

[Kevin Buettner]

On Feb 14,  5:45pm, Mike Brownlow wrote:

>   I thought this would be a good opportunity to raise a question I
> have about the TUI in GDB. I have recently registered my libtui as a
> project on freshmeat, before I knew that my favorite debugger had
> a libtui in it. I'm wondering if this would cause problems for
> anybody? Should I change my lib's name? Or will it not be a big
> deal? I don't want to use libtui if the plans for GDB libtui are
> to release it separately or if GDB programmers dislike the idea of my
> lib having the same name. Obviously GDB TUI has been around longer,
> but I wanted to hear what people think about this.
> 
>   I honestly wasn't aware that a libtui existed yet, but I'm willing
> to change the name for my favorite debugger. :)
> 
>   My lib is at: http://www.wsmake.org/~mike/software/libtui/

Mike,

I don't think there's any need for you to change the name of your
library.  GDB's TUI will likely stay confined to GDB so I doubt that
there will be much confusion.

Kevin

Re: GDB TUI doesn't build

[Mike Brownlow]

Kevin Buettner wrote:
> On Feb 14,  5:45pm, Mike Brownlow wrote:
> >   I honestly wasn't aware that a libtui existed yet, but I'm willing
> > to change the name for my favorite debugger. :)
> > 
> >   My lib is at: http://www.wsmake.org/~mike/software/libtui/
> 
> Mike,
> 
> I don't think there's any need for you to change the name of your
> library.  GDB's TUI will likely stay confined to GDB so I doubt that
> there will be much confusion.
> 
> Kevin

Ahh, great then.

Thanks!

-- 
Mike Brownlow                        http://www.wsmake.org/~mike/
-----------------------------------------------------------------
1024D/8AA6EAFD 3861 96B3 EEA2 285C BE23  F706 3E1E EBB2 8AA6 EAFD
"Hatred stirreth up strifes: but love covereth all sins." Pr10:12