Newsgroups: comp.os.linux.announce
From: jrs@world.std.com (Rick Sladkey)
Subject: UPS Graphical Debugger, Linux version 0.2
Message-ID: <1994Mar10.174851.10196@cs.cornell.edu>
Date: Thu, 10 Mar 1994 17:48:51 GMT
Approved: linux-announce@tc.cornell.edu (Matt Welsh)

UPS was written by Mark Russell <mtr@ukc.ac.uk>.  A blurb about UPS is
at the end of this announcment.

Six months ago I ported the UPS debugger to Linux.  Since then I
have found a few bugs in the port and I added support for more UPS
features.  More importantly, GCC seems to have changed the debugging
information it generates in such a way that the old UPS will hardly
run at all.  So I have patched things up as best as I can and created
a second revision of the diffs.

The file is currently available at:

  sunsite.unc.edu:/pub/Linux/Incoming/ups-2.45.2-linux-0.2.diff.gz

and likely soon at:

  sunsite.unc.edu:/pub/Linux/devel/debuggers/ups-2.45.2-linux-0.2.diff.gz

These diffs should be applied to a virgin UPS distribution such as:

  ftp.x.org:/contrib/ups-2.45.2.tar.Z

Changes since the previous version:

* support for attaching to already running processes
* calling target functions (your own code) from a breakpoint works
* the special include directory is no longer needed with libc 4.5.17 or later
* the Imakefiles probably work
* UPS now pretends to understand `long long' and `unsigned long long' types
* UPS quietly tolerates the `long double' type
* UPS understands octal numbers in debugging stabs

There are only two real problems with UPS on Linux.  One is due to
a limitation in UPS and the other is due to a limitation in Linux.

* Linux makes use of inlined functions in the libc include files.  UPS
  does not correctly handle the case of executable code lines occuring
  in an included file.  Fixing this problem would be non-trivial so I
  didn't do it.  The symptom is that one freqently gets the message
  `No executable code on line' when trying to set a breakpoint.  As a
  work-around you can include a small dummy function at the beginning
  of any file which shows this problem, e.g. `static void dummy(void) {}'.

* When the debugged program is running of its own accord and doesn't
  hit a breakpoint, it is impossible to stop the program from UPS.
  This is because Linux does not (yet) support asynch I/O.  As a
  workaround, you can send a signal to the process from another window
  with `kill -STOP <pid-of-program>'.

After the last announcement I got several bug reports about garbage on
the screen after a menu was removed.  All these reports originated
from people with the then pre-beta XS3 server.  I never discovered
what the problem was since I couldn't duplicate it.

I would like to give special thanks to Karl Olav Lillevold
<Karl.Lillevold@nta.no> who reported most of the problems and helped
me with testing.

Rick Sladkey <jrs@world.std.com>

========= UPS blurb written by the author, Mark Russell ===========

WHAT IS UPS?
------------

Ups is a source level C debugger that runs under X11 or SunView.
It runs in a window with two major regions: one showing the
current state of the target program data and the other showing
the currently executing source code.  A key feature of ups is
that the variables display is persistent: when you add a variable
to the display it stays there as you step through the code.  The
current stack trace (which function called which) is always visible.

Ups includes a C interpreter which allows you to add fragments
of code simply by editing them into the source window (the source
file itself is not modified).  This lets you add debugging printf
calls without recompiling, relinking (or even restarting) the
target program.  You can also add conditional breakpoints in a
natural way - you just add a statement like "if (i == 73) #stop"
at the appropriate place in the source window.

Some things you can do with ups:

   + Add variables to the display by simply clicking on them
     in the source window.

   + Expand (recursively) structures and unions to show their
     members.
	
   + Assign to variables by editing the displayed value.

   + Add breakpoints by pointing with the mouse at the line
     where you want execution to stop.
	
   + Add interpreted code at any breakpoint, including code that
     calls compiled functions and assigns to variables.

It's hard to describe an interactive application in a few paragraphs of
text - the best way to see what ups is like grab a copy and try it.
There's a walkthrough debugging session in the manual page: if you work
through this and aren't hooked at the end of it then I'll give you
your money back :-)


HOW UPS DIFFERS FROM XXGDB, XDBX AND DBXTOOL
--------------------------------------------

The key implementation difference between ups and the various X front
ends for dbx and gdb is that ups is not a front end for a command based
debugger.  Xdbx and xgdb give you a convenient way to invoke the
underlying debugger's commands, but it is fairly clear in both that
you are talking to a text based debugger.  Ups in the other hand is
a complete native debugger implementation; there is no underlying
command language.

An example: to print the value of a variable in xgdb you select (by
dragging) a variable name and then click on `print' in the menu.  Xgdb
passes the print command with the selection to gdb and displays the
result.  By contract in ups you click the mouse over a variable name
and it is added to the display.  Once the variable is added to the
display it stays there, so you can watch it change as you step through
the code.  If the variable happens to be a structure or a pointer to a
structure you can `expand' it to show its members.  Again, the
structure members thus added remain in the display until you get rid of
them so you can watch their values change as you execute the code.

Of course there is a downside to not talking to an existing debugger: you
lose portability.  Ups is machine dependent - a port to a new architecture
is a significant effort.  I think the benefits outweigh the cost.
