Re: Gnat on OpenVMS

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <FC3wGF.AFz@news.boeing.com>,
  nickerson@pundit.ds.boeing.com () wrote:
> at one time I tried using the VMS debugger on GNAT
> executables;
> simply link with the /debug flag; then modify the executable
> to be in debug by using one of the various tools that can do
> that; I have not done this lately but will be trying it again
> soon to see if it works;

This will only work to a very limited extent, because the
industry standard format for symbol type information used
by GNAT under VMS (Dwarf-2) is not understood by the VMS
debugger.

Once again, it would be useful to have a rather more specific
idea of what Bart does not like in GDB to see whether they
categorize into:

1. Bugs that have already been fixed
2. Bugs that are straightforward to fix (and that would be
     fixed rapidly if Bart were a customer)
3. Missing functionality that is likely to appear in the future
4. Missing functionality that is unlikely to appear
   4a. fundamental stuff
   4b. personal likes and dislikes

As everyone knows from EMACS/VI discussions, you can waste
infinite time if you get into the 4b area (it is amazing to
me how many people are willing to call one of these two
highly competent editors completely useless).

So if you want to discuss debugging features, it is useful to
be highly specific.

For one thing people want different things. I would find a
debugger that did not have a good interface for calling
functions in the executable unusable, since I could not
dump any of my data. Trying to use standard mechanisms for
dumping complex data is useless to me, since such standard
mechanisms don't understand the *abstract* structure of my
data, only the physical form in which I am not interested.

For example, in GNAT, a universal integer is a high precision
integer represented in some nasty array format. I don't want
to see the array, I want to enter the command

   pid (xxx)

and see the value in decimal, as I can with GDB.

On the other hand, there are people who never ever use this
approach, and don't even know whether their debugger supports
it. They want to use the standard mechanisms for displaying
complex language specific data.

Is either point of view wrong? of course not, just two different
viewpoints. In this case, a debugger can reasonably support
both views, as GDB now does for Ada 95, but you can't always
split the difference this way.

One advantage that GDB has is that the interface and code is
open. This means that you can easily have multiple user
interfaces.

Very often, people like or dislike debuggers not based on the
important part (the basic debugging engine), but rather on the
look and feel of the user interface. Tastes are very different
here. Personally I don't like any of these junk graphic mouse
driven interfaces for a debugger, but some people do like them.
Furthermore if you like them, you tend to have strong feelings
about how they should be set up (multiple windows vs one split
window, etc).

In the case of GDB, there are several interfaces available:

1. standard command line interface
2. DDD
3. GDBTK
4. EMACS

and several more on their way. So if you don't like the feel
of one of these, think about trying another!

Actually most of the problems of GDB on VMS have been related
to the debugging engine itself. VMS lacks the nice clean
separation provided in Unix and NT systems between a debugger
and its client, so basically GDB on VMS has to use a remote
client server model. At this stage, most of the problems that
come from this non-standard setup have been solved, but it
most certainly has not been an easy task.

One good thing is that once these basic issues with fitting GDB
into the restricted VMS model have been solved, then other
general improvements to GDB can be taken advantage of on VMS
with minimal work.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---