[comp.lang.c] Does GNU's C Compiler Have a Full Screen Debugger?

bruce@bmhalh.UUCP (Bruce M. Himebaugh) (10/26/90)

Does the GNU C compiler have a full screen debugger available?  If so, is it
anything like codeview?

Thanks for any information!!!

Bruce
-- 
Bruce M. Himebaugh                                          Voice: 216-484-3528
   PATHS: uunet!{ncoast,aablue}!fmsystm!mrsmouse!bmhalh!bruce
          (NOTE: the system name "fmsystm" is with no "e", NOT "fmsystem")
  *NOTE*: Please do not use bruce@bmhalh.UUCP -- I'm not registered yet.

bob@MorningStar.Com (Bob Sutterfield) (10/27/90)

In article <54@bmhalh.UUCP> bruce@bmhalh.UUCP (Bruce M. Himebaugh) writes:
   Does the GNU C compiler have a full screen debugger available?

GDB is the GNU Debugger.  There exists an X11 interface.  Also, GNU
emacs has a nicely integrated gdb-mode, enabling one to use the
debugger in one window while watching source in another, then diddle
the source, recompile with M-x compile, fix compiler errors with M-x
next-error, and re-start the debugger on the new objects.  It's not as
pretty as, say, SaberC, but it's not bad for free.

   If so, is it anything like codeview?

Sorry, I don't know anything about codeview.

pinard@IRO.UMontreal.CA (Francois Pinard) (10/27/90)

In article <54@bmhalh.UUCP> bruce@bmhalh.UUCP (Bruce M. Himebaugh) writes:

   Does the GNU C compiler have a full screen debugger available?  If so, is it
   anything like codeview?

To my knowledge, gdb is not full screen in the same sense CodeView is.
However, GNU Emacs may to run gdb as a subprocess (the M-x gdb
command), using a two window setup, one for gdb commands, the other
for looking at the source files and setting breakpoints.  Whenever the
execution stops, the source window is automatically repositionned in
the correct file, with an arrow pointing on the current stop position.
Even if some might argue on this, to a certain extent, I consider this
is full screen debugging.
--
Franc,ois Pinard          ``Vivement GNU!''         pinard@iro.umontreal.ca
(514) 588-4656    cp 886 L'Epiphanie (Qc) J0K 1J0    ...!uunet!iros1!pinard

stachour@sctc.com (Paul Stachour) (10/30/90)

>In article <54@bmhalh.UUCP> bruce@bmhalh.UUCP (Bruce M. Himebaugh) writes:
>   Does the GNU C compiler have a full screen debugger available? 
> If so, is it anything like codeview?

  Do you mean the codeview debugger available on MS-DOS with Microsoft-C?

  If so, than I would not call that a full-screen debugger because:

 #1:  It requires two physical screens to do the debugging, one-to-run
      and one-to-debug.
 #2:  It does not allow me to do screen-things on my debuggin screen,
      only line-things.
 #3:  If I have two screens attached to two different machines, I can't
      use it.

  ----
    The quesion for me is 

  1)    "Can the debugger use a full-screen (or part) " to debug
        a program (which may or may not been a screen program)?

    and not

  2)    "Can the debugger be used to debug a screen-program?"

      Certainly, under question "1)" codeview is not a full-screen
          debugger.
      Also many debbuggers (including GDB) are full-screen debuggers
          under "2)", depending on how one connects them to the
          program being debugged.  ...Paul
-- 
Paul Stachour         Secure Computing Technology Corp
stachour@sctc.com      1210 W. County Rd E, Suite 100           
		 	   Arden Hills, MN  55112
                             [1]-(612) 482-7467

eru@tnvsu1.tele.nokia.fi (Erkki Ruohtula) (10/30/90)

In article <PINARD.90Oct27122647@kovic.IRO.UMontreal.CA> pinard@IRO.UMontreal.CA (Francois Pinard) writes:
   In article <54@bmhalh.UUCP> bruce@bmhalh.UUCP (Bruce M. Himebaugh) writes:

      Does the GNU C compiler have a full screen debugger available?  If so,
      is it anything like codeview?

   To my knowledge, gdb is not full screen in the same sense CodeView is.
   However, GNU Emacs may to run gdb as a subprocess (the M-x gdb
   ...
   Even if some might argue on this, to a certain extent, I consider this
   is full screen debugging.

I agree. I have used both CodeView and gdb+emacs, and I like the latter
combination better. For instance, the ability to start directly editing what
you see in the source window (using the same editor you use normally), does
not exist in CodeView.

The only CodeView-feature I miss in gdb+emacs is the separate screen for
program output that prevents program I/O and debugger commands from mixing
(perhaps the gdb mode could be hacked to use a separate Emacs buffer
for debugger I/O?).

--
Erkki Ruohtula     / Nokia Telecommunications
eru@tele.nokia.fi / P.O. Box 33 SF-02601 Espoo, Finland
Disclaimer: These are my private opinions and do not represent the position
            of Nokia Telecommunications.

rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) (10/31/90)

eru@tnvsu1.tele.nokia.fi (Erkki Ruohtula) writes:
>The only CodeView-feature I miss in gdb+emacs is the separate screen for
>program output that prevents program I/O and debugger commands from mixing
>(perhaps the gdb mode could be hacked to use a separate Emacs buffer
>for debugger I/O?).

There's a *really sleazy* way to route the output of your program to a
different window that I've used on occasion.  It works only under X Window,
and is a really cheap hack; no doubt someone can suggest a better way.
Here goes:
   1.	Start up an xterm.  This xterm window will eventually be used for 
the program's output.  When you get a shell prompt, type "tty; sleep 10000"
This will print out the device name (/dev/ttyp?) of the pty for that xterm,
then sleep for hours and hours (meaning you won't have the shell of that 
xterm trying to read from the same tty we'll have our program doing I/O on).
   2.	In another window (either xterm or Emacs), start up gdb on your
program.  Before doing the 'run', issue the command
	tty /dev/ttyp?
where "/dev/ttyp?" is the name of the tty you got in step 1.  Now, all I/O
your program does will be on that tty, hence in that xterm window, and all 
communication with the debugger will be in the original window.  

  Sleazy, but it works....
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  
"MSDOS is a Neanderthal operating system" - Henry Spencer

dd26+@andrew.cmu.edu (Douglas F. DeJulio) (10/31/90)

eru@tnvsu1.tele.nokia.fi (Erkki Ruohtula) writes:
>The only CodeView-feature I miss in gdb+emacs is the separate screen for
>program output that prevents program I/O and debugger commands from mixing
>(perhaps the gdb mode could be hacked to use a separate Emacs buffer
>for debugger I/O?).

rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) writes:
> There's a *really sleazy* way to route the output of your program to a
> different window that I've used on occasion.  It works only under X
> Window...

Why do you say that your method works only under X?  Start up an emacs
shell session (M-x shell) and you can do the same thing in there.
It's still "sleazy", but it gets the desired effect of using three
emacs buffers -- one with source code, one with a debugger, and one
with program output.  This way it will work on a normal terminal.  Not
everyone can stomach the idea of running X11.
-- 
Doug DeJulio

pozar@kumr.UUCP (Tim Pozar) (11/01/90)

In article <1990Oct29.230734.1871@sctc.com> stachour@sctc.com (Paul Stachour) writes:
>  Do you mean the codeview debugger available on MS-DOS with Microsoft-C?
>  If so, than I would not call that a full-screen debugger because:
>
> #1:  It requires two physical screens to do the debugging, one-to-run
>      and one-to-debug.

   Are you saying CodeView needs two different monitors?  If so, I 
have found this to be untrue.  With a keystroke, I can move back and 
forth between the 'debugging' screen with the source, registers, and
varibles displayed and, the "programme output" screen (text or 
graphics).  

   I think what is meant by "Full screen debugger" is that there is 
a method to display the code, registers, ect and not destroy the 
programme's screen at the same time while stepping through the code.  
Old debuggers would use the same screen, therefore destroying what the
programme is painting on the screen.

                      Tim

-- 
  uunet!hoptoad!kumr!pozar Fido: 1:125/555 PaBell: (415) 788-3904
    USNail:  KKSF-FM / 77 Maiden Lane /  San Francisco CA 94108

cgwst@unix.cis.pitt.edu (Charles G. Watson) (11/03/90)

>rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) writes:
>> There's a *really sleazy* way to route the output of your program to a
>> different window that I've used on occasion.  It works only under X
>> Window...

Doesn't sound at all *sleazy* to me.  Instead of X, one can substitute screen
or any another virtual terminal program.  Same exact use of the tty command
will work since screen also uses the pty's.

Sounds like a *damn good* idea to me. 8^}

gray

richard@pegasus.com (Richard Foulk) (11/08/90)

>>> There's a *really sleazy* way to route the output of your program to a
>>> different window that I've used on occasion.  It works only under X
>>> Window...
>
>Doesn't sound at all *sleazy* to me.  Instead of X, one can substitute screen
>or any another virtual terminal program.  Same exact use of the tty command
>will work since screen also uses the pty's.
>

Does anyone know of a version of "screen" that runs on SYSV R.3 386 Unix?



-- 
Richard Foulk		richard@pegasus.com