Re: Gnat on OpenVMS

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <7hshfq$5tc$1@front1.grolier.fr>, "Thierry Lelegard" <lelegard@club-internet.fr> writes:

> The GNAT port to OpenVMS was performed by ACT, with fundings
> from Digital after they decided to drop support for DEC Ada.

Technically speaking, DEC just decided not to advance to Ada95.
A new version of DEC Ada (83) was just released last month on
Alpha (having previously been released on VAX).

Larry Kilgallen

Gnat on OpenVMS

[Thierry Lelegard]

Hello,

My company is currently moving its products from the DEC Ada
compiler to GNAT on OpenVMS Alpha (then, we plan to port to
other operating systems, using GNAT as a common compiler).

The GNAT port to OpenVMS was performed by ACT, with fundings
from Digital after they decided to drop support for DEC Ada.
GNAT does not produce code which is compatible with the OpenVMS
debugger and a special port of GDB was also performed.

We have an incredibly hard time with GNAT on OpenVMS and,
especially, with GDB which can hardly be considered as a
working tool on this operating system.

Is there anyone in the world working with GNAT / GDB on
OpenVMS Alpha? We are very interested in sharing experiments
and usage advices.

Please contact me at lelegard@canal-plus.fr (the reply-to address
is a home one) or directly call me at +33 1 44 25 77 44.

Thanks to everyone in advance.
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: Gnat on OpenVMS

[Robert Dewar]

In article <7hshfq$5tc$1@front1.grolier.fr>,
  "Thierry Lelegard" <lelegard@club-internet.fr> wrote:
> The GNAT port to OpenVMS was performed by ACT, with fundings
> from Digital after they decided to drop support for DEC Ada.
> GNAT does not produce code which is compatible with the
> OpenVMS debugger and a special port of GDB was also performed.

Just a note for the record here. It was a specific contract
requirement from DEC that GDB be used as the debugger, rather
than attempting to use the existing OpenVMS debugger.

Robert Dewar
Ada Core Technologies



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

Re: Gnat on OpenVMS

[Robert Dewar]

In article <7hshfq$5tc$1@front1.grolier.fr>,
  "Thierry Lelegard" <lelegard@club-internet.fr> wrote:

One more comment on GDB on VMS. In the long run, we think that
the DEC decision here was the right one. The big advantage of
using GDB on the VMS port is that it is fully Ada 95 compatible,
something that could not have been achieved with the existing
VMS debugger, since DEC was not in a position to do the
necessary Ada 95 modifications. By using Dwarf-2 as the
format for debugging information, we can take full advantage
of the GNAT encodings and provide complete Ada 95 information
to GDB. We find GDB to work well on VMS (it was used extensively
to debug the compiler itself), and we are confident that Canal
Plus problems (only reported in the last few weeks) can in fact
be solved, there do not seem to be any fundamental difficulties
as far as we can see.

Robert Dewar
Ada Core Technologies


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

Re: Gnat on OpenVMS

[Gautier]

> Technically speaking, DEC just decided not to advance to Ada95.
> A new version of DEC Ada (83) was just released last month on
> Alpha (having previously been released on VAX).

Oh surprise! It's now Compaq Ada 3.5 -> http://www.digital.com/info/SP4500/

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Gnat on OpenVMS

[Robert Dewar]

In article <1999May18.173417.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <7hshfq$5tc$1@front1.grolier.fr>, "Thierry
Lelegard" <lelegard@club-internet.fr> writes:
>
> > The GNAT port to OpenVMS was performed by ACT, with fundings
> > from Digital after they decided to drop support for DEC Ada.
>
> Technically speaking, DEC just decided not to advance to
Ada95.
> A new version of DEC Ada (83) was just released last month on
> Alpha (having previously been released on VAX).

Right, but unfortunately, they have apparently decided not
to continue support on Ada 83, and have informed their customers
that the lifetime of this support is limited.


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

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <7hv83e$t2o$1@front4.grolier.fr>, "Thierry Lelegard" <lelegard@club-internet.fr> writes:

> I am not in love with the OpenVMS debugger, I just appreciate
> its functionalities. If GDB can achieve the same features,
> even with a different user interface (I don't care),
> I will be delighted to use it.

I have never used GDB, but the potential problem that concerns me
is debugging a multilingual program.  If one calls from Ada into
Bliss or PL/I, I presume GDB is not going to step through that
with beautiful debugging ability in both the Ada and non-Ada parts.
For those who prefer DEC C, I suppose it is possible to debug under
GNU and then switch to DEC C for qualification testing.

Of course I am not saying that things would be perfect with some
other arrangement.

Larry Kilgallen

Re: Gnat on OpenVMS

[Daniel Thonon]

Thierry Lelegard wrote:

> Hello,
>
> My company is currently moving its products from the DEC Ada
> compiler to GNAT on OpenVMS Alpha (then, we plan to port to
> other operating systems, using GNAT as a common compiler).
>

We also ported our application from OpenVMS+DECAda to Digital UNIX +
DECAda to Digital UNIX + gnat. We found that the performance was
degraded by a factor of 2 or 3 between DECAda and gnat. Have you sen
anything of the sort with your port ?

Daniel THONON (mailto:Daniel.Thonon@grenoble.sema.fr)
Sema Group (http://www.semagroup.com) Division Energie et Industrie
36, chemin du Vieux Chene BP 104 - 38243 MEYLAN Cedex - FRANCE
Tel : (+33) 4 76 41 46 68   Fax : (+33) 4 76 90 08 63

Re: Gnat on OpenVMS

[Thierry Lelegard]

> We also ported our application from OpenVMS+DECAda to Digital UNIX +
> DECAda to Digital UNIX + gnat. We found that the performance was
> degraded by a factor of 2 or 3 between DECAda and gnat. Have you sen
> anything of the sort with your port ?

Yes, roughly. However, I must admit that our tests are not
completed yet. Before testing the speed, we must get a
functional application, which we did not achieve yet...

Among nine large applications, only one works with gnat
at the present time. The source code is the same at the
working code with DEC Ada (with Ada 83/95 incompatibilites
fixed, at least those that the compiler can see, maybe
not all subtle behavior differences).

You observed a performance degradation by a factor of 2 or 3.
I suppose that this can be easily explained: the size of the
code is larger by the same factor.

For instance, we observed the following sizes:
- EXE generated with DEC Ada, no debug info: 9,000 blocks
- EXE generated with GNAT, no debug info: 19,000 blocks
- EXE generated with GNAT, with debug info: 32,000 blocks

I was forced to look at the generated code because some
programs experienced strange Program_Error (not elab pb) and
GDB failed when we tried to debug it. So, since I was crazy
enough in the past to work with Alpha assembler, I decided
to find the pb by reading the .S file. The code is uncredibly
unefficient, even with /optim=all: no visible instruction
rescheduling (critical issue on Alpha), "strange" usage
of registers and memory, redundant branches, etc. I have
often looked at GEM-generated code in the past, optimized
gnat code looks like non-optimized gem code.

Anyway, all of these issues may be improved in the future,
although the effort to improve the efficiency of a code
generator is huge.

Our immediate concern is to get a working environment
(I mean compiler/debugger, not the applications) and
ACT is currently working on this (we already got a new
version of the compiler, so they really work on it!).

Daniel, did you use GDB on OpenVMS? Did you run into
specific problems? 

I am not in love with the OpenVMS debugger, I just appreciate
its functionalities. If GDB can achieve the same features,
even with a different user interface (I don't care),
I will be delighted to use it.

Note: please answer to lelegard@canal-plus.fr, not the
"reply-to" address of this note.
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: Gnat on OpenVMS

[Robert Dewar]

In article <7hv83e$t2o$1@front4.grolier.fr>,
  "Thierry Lelegard" <lelegard@club-internet.fr> wrote:
> I was forced to look at the generated code because some
> programs experienced strange Program_Error (not elab pb) and
> GDB failed when we tried to debug it. So, since I was crazy
> enough in the past to work with Alpha assembler, I decided
> to find the pb by reading the .S file. The code is uncredibly
> unefficient, even with /optim=all: no visible instruction
> rescheduling (critical issue on Alpha), "strange" usage
> of registers and memory, redundant branches, etc. I have
> often looked at GEM-generated code in the past, optimized
> gnat code looks like non-optimized gem code.

From this description it is clear that you are looking
at unoptimized GNAT code rather than optimized code. Indeed
it is the case that -O0 in gcc produces very inefficient
code. When you tell gcc not to optimize your code, it really
believes you, and does not do even the most elementary
optimizations. In addition there is no scheduling at all
in this mode.

Now, I realize you said you had said /OPTIMIZE=ALL here, so
something very strange is going on. For some reason, this
switch does not seem to be working in your environment. It
works in ours, and we definitely have not seen this problem
before. You should submit details to report@gnat.com.

In fact the code generation for the Alpha is very good. This
is one of the ports on which a lot of effort has been spent
on optimization, and in particular Digital contributed
scheduling code to gcc for the specific purpose of making
sure that gcc would do effective scheduling for this target.

What we have found in practice is that GNAT execution
efficiency is overall comparable to DEC ADa 83. For some
cases of pure computation, GNAT is significantly faster.
For some tasking and I/O cases, GNAT is slower (the range
we have seen is 2-1 in either direction, but that is at
the extreme, most cases are much closer to comparable).

No one claims that gcc generates the best conceivable code
in all circumstances. Indeed such a claim cannot be made
for any compiler, but the code quality from gcc in general
is excellent, and if you see something *THIS* far away from
reasonable code, it is likely that something is significantly
messed up in the installation or procedures.

Robert Dewar
Ada Core Technologies


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

Re: Gnat on OpenVMS

[Robert Dewar]

In article <1999May19.172621.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <7hv83e$t2o$1@front4.grolier.fr>, "Thierry
Lelegard" <lelegard@club-internet.fr> writes:

> I have never used GDB, but the potential problem
> that concerns me is debugging a multilingual program.
> If one calls from Ada into
> Bliss or PL/I, I presume GDB is not going to step through that
> with beautiful debugging ability in both the Ada and non-Ada
> parts.

That's a legitimate concern. I think we can all agree that
it would have been desirable to be fully integrated with
the old VMS debugger, but unfortunately this would have
required significant work (to accomodate Ada 95) and that
was not about to happen.

GDB does of course handle multi-lingual debugging well if
all languages are generating a debugging format that GDB
understands.

As Larry says, one solution, at least in the C case, is to
debug using GNU C, and then switch later if necessary.

Another approach, perhaps the best for the long term, is to
teach the other Digital compilers to be GDB compatible. This
is by no means impossible. It could be done on the GDB side
by teaching GDB about the DEC-specific format used now, or
it could be done on the compiler side by having the DEC
compilers generate one of the industry standard formats.

I think this approach may make better sense in the long run,
since we will see major development in GDB over the next
couple of years, addressing such features as multi-processing
and scalability, since there seems to be a significant
movement in the direction of adopting GDB from several
hardware manufacturers, and of course the GNU-Linux work
will result in continuing improvement of GDB.

I suspect this was at least part of the thinking on Digital's
part in requiring the use of GDB as the debugging solution
for GNAT/VMS.

Robert Dewar
Ada Core Technologies


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

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <3744EFE6.79F99405@wanadoo.fr>, Daniel Thonon <Daniel.Thonon@wanadoo.fr> writes:

> I also looked at the code generated by gnat on Digital UNIX (with
> different -O levels and chip dependant optimizations) and found the same
> kind of problem. For example, just by counting the number of statements
> in a loop, I found a ratio of more than 2 between gnat and DECAda. The
> GEM code was quite simple to understand, but the gnat code was very
> complicated, with several unnecessary jumps, for example.

Be very careful with Alpha (and other RISC machines, I would presume)
to avoid seat-of-the-pants judgements about what is complicated.  It
may be that you have studied this in detail, or maybe not, but what
seems like an obvious cost comparison can often be subtle.  Looking
at GEM (DEC) code from various compilers one can find things like
NOP instructions inserted, not for "wait state" purposes but to make
branch targets have quadword alignment.

I would certainly not claim that the machine code you describe is good,
because I have not seen it.  For Alpha code I have seen, however, what
seemed questionable to me at the start actually had a reason for being
that way.  It is of course possible that you are much more expert than
I in the timing of the Alpha chip, but I make this post anyway on the
theory that someone else out there may be less expert :-).

> We did not find the same conclusion, either on simple benchmarks or with
> our complete application. In some case, gnat is faster, but overall it
> is really slower.

Yes, your application is the real test, since it was your organization
that wants the computing done, not the SPEC committee.

Larry Kilgallen

Re: Gnat on OpenVMS

[nickerson]

In article <7hshfq$5tc$1@front1.grolier.fr>, 
"Thierry Lelegard" <lelegard@club-internet.fr> writes:

|>My company is currently moving its products from the DEC Ada
|>compiler to GNAT on OpenVMS Alpha (then, we plan to port to
|>other operating systems, using GNAT as a common compiler).
|>
|>The GNAT port to OpenVMS was performed by ACT, with fundings
|>from Digital after they decided to drop support for DEC Ada.
|>GNAT does not produce code which is compatible with the OpenVMS
|>debugger and a special port of GDB was also performed.

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;

|>We have an incredibly hard time with GNAT on OpenVMS and,
|>especially, with GDB which can hardly be considered as a
|>working tool on this operating system.

totally agree; GDB described as a "full featured debugger" bring 
to mind the word impostor;

|>Is there anyone in the world working with GNAT / GDB on
|>OpenVMS Alpha? We are very interested in sharing experiments
|>and usage advices.

I am using it on an experimental basis but really have nothing
beyond several rants to share right now;

|>Thanks to everyone in advance.
|>________________________________________________________
|>Thierry Lelegard, Paris, France
|>E-mail: lelegard@club-internet.fr

--(bn) Bart Nickerson
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Gnat on OpenVMS

[nickerson]

In article <7ht4m2$4k7$1@nnrp1.deja.com>,
 Robert Dewar <robert_dewar@my-dejanews.com> writes:
|>One more comment on GDB on VMS. In the long run, we think that
|>the DEC decision here was the right one. The big advantage of
|>using GDB on the VMS port is that it is fully Ada 95 compatible,
|>something that could not have been achieved with the existing
|>VMS debugger, since DEC was not in a position to do the
|>necessary Ada 95 modifications. By using Dwarf-2 as the
|>format for debugging information, we can take full advantage
|>of the GNAT encodings and provide complete Ada 95 information
|>to GDB. We find GDB to work well on VMS (it was used extensively
|>to debug the compiler itself), and we are confident that Canal
|>Plus problems (only reported in the last few weeks) can in fact
|>be solved, there do not seem to be any fundamental difficulties
|>as far as we can see.
|>
|>Robert Dewar
|>Ada Core Technologies

wrong; totally & utterly wrong direction; DEC made what I would
imagine is a $ decision; you should not subsequently call that
(by implication) the correct technical decision; 

GDB may be Ada95 knowledgeable but it is nowhere close to the
VMS debugger in capablity & usablity; based on my brief trials 
with GDB (full screen) it will never get close; that opinion
coupled with GDB not being the native OS debugger gives a drastic 
fault in GNAT's applicablity; (but then it is the only game in 
town for Ada95);

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Gnat on OpenVMS

[Daniel Thonon]

Robert Dewar wrote:

> In article <7hv83e$t2o$1@front4.grolier.fr>,
>   "Thierry Lelegard" <lelegard@club-internet.fr> wrote:
> > I was forced to look at the generated code because some
> > programs experienced strange Program_Error (not elab pb) and
> > GDB failed when we tried to debug it. So, since I was crazy
> > enough in the past to work with Alpha assembler, I decided
> > to find the pb by reading the .S file. The code is uncredibly
> > unefficient, even with /optim=all: no visible instruction
> > rescheduling (critical issue on Alpha), "strange" usage
> > of registers and memory, redundant branches, etc. I have
> > often looked at GEM-generated code in the past, optimized
> > gnat code looks like non-optimized gem code.
>
> From this description it is clear that you are looking
> at unoptimized GNAT code rather than optimized code. Indeed
> it is the case that -O0 in gcc produces very inefficient
> code. When you tell gcc not to optimize your code, it really
> believes you, and does not do even the most elementary
> optimizations. In addition there is no scheduling at all
> in this mode.

I also looked at the code generated by gnat on Digital UNIX (with
different -O levels and chip dependant optimizations) and found the same
kind of problem. For example, just by counting the number of statements
in a loop, I found a ratio of more than 2 between gnat and DECAda. The
GEM code was quite simple to understand, but the gnat code was very
complicated, with several unnecessary jumps, for example.

>
> What we have found in practice is that GNAT execution
> efficiency is overall comparable to DEC ADa 83. For some
> cases of pure computation, GNAT is significantly faster.
> For some tasking and I/O cases, GNAT is slower (the range
> we have seen is 2-1 in either direction, but that is at
> the extreme, most cases are much closer to comparable).

We did not find the same conclusion, either on simple benchmarks or with
our complete application. In some case, gnat is faster, but overall it
is really slower. We allready spoke with ACTE about that, but without
concluding.
--
Daniel THONON (mailto:Daniel.Thonon@grenoble.sema.fr)
Sema Group (http://www.semagroup.com) Division Energie et Industrie
36, chemin du Vieux Chene BP 104 - 38243 MEYLAN Cedex - FRANCE
Tel : (+33) 4 76 41 46 68   Fax : (+33) 4 76 90 08 63

Re: Gnat on OpenVMS

[Robert Dewar]

In article <FC3vx8.5qG@news.boeing.com>,
  nickerson@pundit.ds.boeing.com () wrote:
> wrong; totally & utterly wrong direction; DEC made what I
> would imagine is a $ decision; you should not subsequently
> call that (by implication) the correct technical decision;

Well sure, if DEC had been willing to invest the resources to
update the VMS debugger, not only with respect to Ada 95, but
also with respect to other shortcomings (e.g. lack of
scalability to the multi-processing environment), then that
would have been fine. But given that this was not going to
happen (not just for $$$ reason but for many other reasons),
it was not a viable route.

Note that it was not just $$$ reasons at all here, but also
a significant change in direction for DEC. In downsizing to
avoid extinction, the decision was to do far less in house.
FOr example, Ada was a profitable product for DEC. The decision
to abandon their own Ada technology was not simply a $$$ one
but also a consequence of general trimming back. This often
happens in this situation.

> GDB may be Ada95 knowledgeable but it is nowhere close to the
> VMS debugger in capablity & usablity; based on my brief trials
> with GDB (full screen) it will never get close; that opinion
> coupled with GDB not being the native OS debugger gives a
> drastic  fault in GNAT's applicablity; (but then it is the
> only game in  town for Ada95);

Well it would be a little more useful if you would be more
specific about what you like or don't like about debuggers,
so we can see if there are useful technical points. My
experience is that people have highly subjective views on
the subject, as with editors. And as for the "it will never
get close", you do not begin to have the information to make
that claim. You have not even seen the most up to date version,
let alone what is in the wings!

Right now, there are perhaps 20 or so full time people working
on GDB, perhaps more. 90% of this work is target independent,
and will benefit all users of GDB.

VMS is in a way quite analogous to Ada. A technology with
significantly superior capability in many respects, but one
which is just a niche. With VMS, as with Ada 95, this means
that you need to piggy-back on top of work done for other
platforms as much as possible if you want to keep the
technology alive.


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

Re: Gnat on OpenVMS

[Robert Dewar]

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

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <FC3vx8.5qG@news.boeing.com>, nickerson@pundit.ds.boeing.com () writes:

> imagine is a $ decision; you should not subsequently call that
> (by implication) the correct technical decision; 
> 
> GDB may be Ada95 knowledgeable but it is nowhere close to the
> VMS debugger in capablity & usablity;

The VMS debugger is actually maintained by the group that maintains
the operating system (as contrasted with days of yore, when it was
maintained by the compiler folks).  As a result it is starting to get
incorporated more and more into tools like crash dump analysis and
process dump analysis (if you want an example of something that has
_never_ been good on VMS it is process dump analysis, but they know
it and have gotten what is probably sufficient pressure to fix it).

So for those who might receive a dump file in the mail from a VMS
customer, the analysis tool is now and will continue to be tightly
coupled to the VMS debugger.  Some people may use Ada on VMS just
to test drive code that will really be used in an embedded situation,
but there are others who use it for production jobs that run on VMS.

Larry Kilgallen

Re: Gnat on OpenVMS

[Robert Dewar]

In article <7i74fa$9e2$1@front6.grolier.fr>,
  "Thierry Lelegard" <lelegard@club-internet.fr> wrote:

> Honestly, I hardly understand why it was so difficult to
> integrate with the VMS debugger. The format of the debug
> tables
> is public (appendix of the linker manual).

Nobody said that it was "so difficult". I think Digital's
decision to require GDB as the base was not necessarily based
only bevcause it was difficult, although it would have been
relatively expensive, since it would have required even more
VMS-specific work in GNAT (which is a major maintenance issue
as well as a development issue).

Instead, my analysis is that Digital saw it as the best long
term choice, since they knew that with GDB, unlike the VMS
debugger, significant long term development and improvement
efforts would continue.

> All GNAT-specific
> features could have been implemented by GNAT using a DBGEXT
> entry in the GNAT RTL. The syntax of data is similar in Ada
> 83 and 95 and is already supported by the VMS debugger.

There are many features that would NOT have been well supported,
e.g. modular types, child units, tagged types (as you note),
Ada 95 attributes.

In addition, there are places where GNAT uses a different
approach from DEC Ada 83, and so the fact that the debugger
supports the Ada 83 approach would not help GNAT (e.g. proper
support of fat pointers for unconstrained types).

We did actually provide some minimal compatibility with
the VMS debugger to get the VMS traceback working correctly
(so line numbers and subprogram entries can be understood),
but the types do not attempt to use DEC Ada 83.

Robert Dewar
Ada Core Technologies




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

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <7i74fa$9e2$1@front6.grolier.fr>, "Thierry Lelegard" <lelegard@club-internet.fr> writes:

> However, just allow me to think that crashing with "ACCVIO,
> access violation" is an "unaesthetic" and "unfriendly" reply to
> valid commands ;-)

Actually it is an inappropriate response to even invalid commands.
Of course I do not think anyone claims this response was a design
goal, so thus it is a bug, susceptible to a fix.  I have seen such
bugs even in the DEC debugger.

> So, each OS defines its own concepts of a debugger. If a
> debugger fits in this model, it can be very powerful. If
> it refuses this model, it will always be inferior to native
> debuggers.

There may be some economics at work here, as GDB folk are accustomed
to moving readily between many operating systems so long as they are
all some form of Unix.  GDB would not be so pervasive if the great
debugger support was provided as first priority on VMS, HP-MPE, MacOS,
MVS, OS/400, and all those flavors of Windows.

> Honestly, I hardly understand why it was so difficult to
> integrate with the VMS debugger. The format of the debug tables
> is public (appendix of the linker manual). All GNAT-specific
> features could have been implemented by GNAT using a DBGEXT
> entry in the GNAT RTL. The syntax of data is similar in Ada
> 83 and 95 and is already supported by the VMS debugger.

It certainly is legally difficult if the contract from DEC said not
to integrate with the VMS debugger.  Of course that contract is only
binding on ACT (and DEC), so somebody else could make changes to GNAT,
although for Robert to suggest such an action would probably be bad
form.

Larry Kilgallen

Re: Gnat on OpenVMS

[Thierry Lelegard]

Robert Dewar <robert_dewar@my-dejanews.com> a �crit dans le message :
> 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.

Well, at the present time, we only use the GDB command line
interface and we have no objection in using its syntax.

However, just allow me to think that crashing with "ACCVIO,
access violation" is an "unaesthetic" and "unfriendly" reply to
valid commands ;-)

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

VMS has its own definition of a debugger. The image activator
($IMGSTA phase) includes support for debugger activation. There
is a specific exception vector which is reserved for the debugger.
Most RTL's (such as ada and pthread RTL's) implement a standart
mechnisme called DBGEXT to interact with the debuggers.

These mechanisms are not exclusively used by VMSDEBUG. They
are also used by PCA, the performance analyzer.

I also used all these mechanisms to implement a "sort of"
debugger (actually, a spying tool for tracking random and
rare problems which appear only after a very long run in
an operational environment).

So, each OS defines its own concepts of a debugger. If a
debugger fits in this model, it can be very powerful. If
it refuses this model, it will always be inferior to native
debuggers.

GDB may be a good tool but it was design based on the UNIX
model of debugging. On VMS, GDB looks like me in an English
speaking environment: I understand most of what people say
but I remain a native French speaker and I do not always
understand fast speakers, specific or cultural jokes.
British and American people may like or hate me but,
for them, discussing with me will never be as easy as with
their fellow native English speakers.

Honestly, I hardly understand why it was so difficult to
integrate with the VMS debugger. The format of the debug tables
is public (appendix of the linker manual). All GNAT-specific
features could have been implemented by GNAT using a DBGEXT
entry in the GNAT RTL. The syntax of data is similar in Ada
83 and 95 and is already supported by the VMS debugger.
I agree that some OO features of Ada95 could be not very
well formatted (but GDB does not perform well either in
this area).

-Thierry
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: Gnat on OpenVMS

[Robert Dewar]

In article <1999May22.193351.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> It certainly is legally difficult if the contract from DEC
> said not to integrate with the VMS debugger.  Of course that
> contract is only binding on ACT (and DEC), so somebody else
> could make changes to GNAT, although for Robert to suggest
> such an action would probably be bad form.
>
> Larry Kilgallen

Just to clarify, the contract had no clause *forbidding*
integration with the VMS debugger. Rather it insisted on full
integration of GDB, so this is where the majority of the work
went. I think there were the following issues involved:

  1. Digital does not see major long term investment happening
     in the future for the VMS debugger, and so there is an
     advantage in shifting in the GDB direction (a number of
     other work station manufacturers are moving towards GDB
     for the same reasons).

  2. In particular, there was no possibility of finding
     resources at Digital for Ada 95 specific modifications
     to the VMS debugger (remember that Digital's first
     inclination was to completely abandon Ada on VMS and
     push all their customers to DEC Unix, it was only when
     a number of customers notified Digital that this was
     not acceptable, that some attention was given to Ada 95
     on VMS.

  3. Adapting GNAT to use the VMS debugger would have been a
     major work item. Would it have been more expensive than
     adapting GDB? Probably, but who knows, we were never asked
     to bid on that adaptation.

We did in fact do some minimal integration with the VMS
debugger, line numbers and procedure names are compatible,
and you can look at some very simple kinds of data. This was
useful for getting the backtrace to work anyway. But complex
data cannot be viewed.

With some (non-trivial) amount of work, the integration with
VMS debug could be greatly improved. But no one seems interested
in funding this at the current time.

Note that Digital was not unaware of the issues of switching
debuggers. During the formal field test, Bart Nickerson made
it clear that he would never be happy with anything other than
the VMS debugger, and so Digital was quite aware that some
segment of the market would feel this way, and perhaps always
will (VMS users can be quite opinionated :-) like Ada folks :-)

One thing is certain and that is that GDB continues to improve
at a rapid pace, and we have found that most problems reported
have been in the category of bugs that can be fixed in a fairly
straightforward manner. In addition, major improvements to GDB
continue to occur from our work, and also the work at Cygnus,
and several other large companies (I am not sure I can give
names at the current time, but you can expect some interesting
announcements in the near future, both concerning companies
adopting GDB, and concerning the maintenance of GDB itself).

Yes, there will be some people who always will prefer the VMS
debugger, and just as no amount of improvement to VI will woo
away EMACS users, I am sure they will feel that way
indefinitely. But in the long run, we are confident that VMS
Ada users will find that GDB meets their requirements, and
indeed a number of users are finding that it works fine for
them right now.

And by the way Larry, if someone wants to contribute the changes
to make GNAT work better with VMS debug, that would be fine with
us, I would be delighted to see that happen, it is just that ACT
does not begin to have the resources to fund such work itself at
the current time.

Robert Dewar
Ada Core Technologies




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

Re: Gnat on OpenVMS

[Robert Dewar]

In article <1999May22.193351.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

> There may be some economics at work here, as GDB folk are
> accustomed to moving readily between many operating systems so
> long as they are all some form of Unix.

No, they don't need to be some form of Unix, GDB is being
used successfully on many non-Unix operating systems. Indeed
all my own personal work is on OS/2, where GDB works just fine.

I think it is definitely true that people who move between many
targets prefer tools that are uniform across targets. We have
a couple of users of the VMS version who simply have a
requirement to produce a VMS version of their software, but
they also work on many other platforms. People in this position
are of course far happier to use GDB than the VMS debugger,
since they do not want to learn idiosyncratic target dependent
tools for each target.

Actually I see nothing specially unixy about GDBTK (or DDD for
that matter). The whole point of TK or GTK is to provide target
independence for GUI's. There may be things you don't like about
GDBTK, but I doubt they are specifically unix related in any
sense. Equally there may be things you like, but there again,
I doubt there is any real unix involvement.

Robert Dewar
Ada Core Technologies


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

Re: Gnat on OpenVMS

[nickerson]

In article <7i98qg$dhr$1@nnrp1.deja.com>, 
Robert Dewar <dewar@gnat.com> writes:
|>In article <1999May22.193351.1@eisner>,
|>  Kilgallen@eisner.decus.org.nospam wrote:
|>
|>> There may be some economics at work here, as GDB folk are
|>> accustomed to moving readily between many operating systems so
|>> long as they are all some form of Unix.
|>
|>No, they don't need to be some form of Unix, GDB is being
|>used successfully on many non-Unix operating systems. Indeed
|>all my own personal work is on OS/2, where GDB works just fine.
|>
|>I think it is definitely true that people who move between many
|>targets prefer tools that are uniform across targets. We have
|>a couple of users of the VMS version who simply have a
|>requirement to produce a VMS version of their software, but
|>they also work on many other platforms. People in this position
|>are of course far happier to use GDB than the VMS debugger,
|>since they do not want to learn idiosyncratic target dependent
|>tools for each target.

actually "it is definitely true" is NOT a true statement; it is
your reading of the tea leaves; counterexample - I also program 
on DUX (Digital UNIX - now Compaq's Tru64 unix), and on that 
platform I prefer the "native debugger" ladebug and not GDB;
again that is because of the usability of ladebug (hint: it looks
a lot like VMSdebugger to me) and my lack of expertise with GDB; 

(I will attempt to remedy my ignorance and give a more informed 
critique as time permits);

|>Actually I see nothing specially unixy about GDBTK (or DDD for
|>that matter). The whole point of TK or GTK is to provide target
|>independence for GUI's. There may be things you don't like about
|>GDBTK, but I doubt they are specifically unix related in any
|>sense. Equally there may be things you like, but there again,
|>I doubt there is any real unix involvement.
|>
|>Robert Dewar
|>Ada Core Technologies

on VMS the need for a fullscreen debugger meant that you had to
also provide tcl/tk; not necessarily a trivial task, but OTOH a
nice service;

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Gnat on OpenVMS

[nickerson]

In article <7i98hl$d8a$1@nnrp1.deja.com>, 
Robert Dewar <robert_dewar@my-dejanews.com> writes:
|>
|>Just to clarify, the contract had no clause *forbidding*
|>integration with the VMS debugger. Rather it insisted on full
|>integration of GDB, so this is where the majority of the work
|>went. I think there were the following issues involved:
|>
|>  1. Digital does not see major long term investment happening
|>     in the future for the VMS debugger, and so there is an
|>     advantage in shifting in the GDB direction (a number of
|>     other work station manufacturers are moving towards GDB
|>     for the same reasons).

are you implying that the VMS debugger is to be dropped in favor
of GDB; I find that a big statement and needing of further proof;

|>  2. In particular, there was no possibility of finding
|>     resources at Digital for Ada 95 specific modifications
|>     to the VMS debugger (remember that Digital's first
|>     inclination was to completely abandon Ada on VMS and
|>     push all their customers to DEC Unix, it was only when
|>     a number of customers notified Digital that this was
|>     not acceptable, that some attention was given to Ada 95
|>     on VMS.

I am unable to rationally comment on Digital's eratic behaviors;

|>  3. Adapting GNAT to use the VMS debugger would have been a
|>     major work item. Would it have been more expensive than
|>     adapting GDB? Probably, but who knows, we were never asked
|>     to bid on that adaptation.

yes DEC made a $ decision; it was the wrong decision;

|>We did in fact do some minimal integration with the VMS
|>debugger, line numbers and procedure names are compatible,
|>and you can look at some very simple kinds of data. This was
|>useful for getting the backtrace to work anyway. But complex
|>data cannot be viewed.

that actually is my usual level of need in VMSdebug; line #s, 
call stack, threads (nowdays), and with only simple expression 
evaluations;

|>With some (non-trivial) amount of work, the integration with
|>VMS debug could be greatly improved. But no one seems interested
|>in funding this at the current time.
|>
|>Note that Digital was not unaware of the issues of switching
|>debuggers. During the formal field test, Bart Nickerson made
|>it clear that he would never be happy with anything other than
|>the VMS debugger, and so Digital was quite aware that some
|>segment of the market would feel this way, and perhaps always
|>will (VMS users can be quite opinionated :-) like Ada folks :-)

that's me;

|>One thing is certain and that is that GDB continues to improve
|>at a rapid pace, and we have found that most problems reported
|>have been in the category of bugs that can be fixed in a fairly
|>straightforward manner. In addition, major improvements to GDB
|>continue to occur from our work, and also the work at Cygnus,
|>and several other large companies (I am not sure I can give
|>names at the current time, but you can expect some interesting
|>announcements in the near future, both concerning companies
|>adopting GDB, and concerning the maintenance of GDB itself).

unless and until it is the native VMS debugger GDB is a nonstarter;
the mixed language case (? wasn't it Larry Kilgallen who pointed
this out) also raises its head here;

|>Yes, there will be some people who always will prefer the VMS
|>debugger, and just as no amount of improvement to VI will woo
|>away EMACS users, I am sure they will feel that way
|>indefinitely. But in the long run, we are confident that VMS
|>Ada users will find that GDB meets their requirements, and
|>indeed a number of users are finding that it works fine for
|>them right now.

the native editor of VMS is the TPU editor; given that I started
with VMS when edt was native that is the keypad of choice; neither 
VI nor EMACS are on the event horizon for me - I'd go with NEDIT;
I have heard of EMACS with edt keypad but there again even the look
of EMACS puts me off;

|>And by the way Larry, if someone wants to contribute the changes
|>to make GNAT work better with VMS debug, that would be fine with
|>us, I would be delighted to see that happen, it is just that ACT
|>does not begin to have the resources to fund such work itself at
|>the current time.
|>
|>Robert Dewar
|>Ada Core Technologies

I understand the lack of resources; but I continue to believe that
GDB is the wrong direction on VMS; 

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Gnat on OpenVMS

[nickerson]

In article <7i6a5g$hjq$1@nnrp1.deja.com>, 
Robert Dewar <robert_dewar@my-dejanews.com> writes:

|>Well sure, if DEC had been willing to invest the resources to
|>update the VMS debugger, not only with respect to Ada 95, but
|>also with respect to other shortcomings (e.g. lack of
|>scalability to the multi-processing environment), then that
|>would have been fine. But given that this was not going to
|>happen (not just for $$$ reason but for many other reasons),
|>it was not a viable route.

am not familiar with limitations or the internals involved; my
understanding would be that there is a basic debug engine and it
is coupled with each specific, supported language's "module" for
expression evalutation & whatnot; could you give a critique of
the shortcomings as you see them;

..snip 

|>Well it would be a little more useful if you would be more
|>specific about what you like or don't like about debuggers,
|>so we can see if there are useful technical points. My
|>experience is that people have highly subjective views on
|>the subject, as with editors. And as for the "it will never
|>get close", you do not begin to have the information to make
|>that claim. You have not even seen the most up to date version,
|>let alone what is in the wings!

I agree that I need to be more constructive and detailed but the
barrier to entry is high and I don't know when I'll be able to do
that; naturally if 3.11p is not up to snuff then the target is moving;

|>Right now, there are perhaps 20 or so full time people working
|>on GDB, perhaps more. 90% of this work is target independent,
|>and will benefit all users of GDB.
|>
|>VMS is in a way quite analogous to Ada. A technology with
|>significantly superior capability in many respects, but one
|>which is just a niche. With VMS, as with Ada 95, this means
|>that you need to piggy-back on top of work done for other
|>platforms as much as possible if you want to keep the
|>technology alive.

ok we are a niche; but I disagree with your piggyback conclusion; 
one can just as well argue that one needn't have any GDB on VMS - 
you should use the documented interfaces and the already existing
VMSdebugger; putting a bit of effort into an Ada95 language 
module for VMSdebug would have been sufficient and that would 
have been that;

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Gnat on OpenVMS

[Robert Dewar]

In article <FC9A9F.A48@news.boeing.com>,
  nickerson@mirage.boeing.com () wrote:
> you should use the documented interfaces and the already
> existing
> VMSdebugger; putting a bit of effort into an Ada95 language
> module for VMSdebug would have been sufficient and that would
> have been that;


Possibly so, but as you know well, Digital was unwilling to
follow this route, they did not feel that it was practical
to expect any work on VMSdebug for Ada (and most certainly
we could not do that work ourselves!)

Robert Dewar
Ada Core Technologies


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

Re: Gnat on OpenVMS

[Mike]

In article <FC99Mz.5up@news.boeing.com>, nickerson@pundit.ds.boeing.com says...
 
>
>I am unable to rationally comment on Digital's eratic behaviors;
>

folks, it is called COMPAQ now, not digital !

There is no more DEC, it is COMPAQ!  

Mike
 

Re: Gnat on OpenVMS

[Matthew Whiting]

Mike wrote:
> 
> In article <FC99Mz.5up@news.boeing.com>, nickerson@pundit.ds.boeing.com says...
> 
> >
> >I am unable to rationally comment on Digital's eratic behaviors;
> >
> 
> folks, it is called COMPAQ now, not digital !
> 
> There is no more DEC, it is COMPAQ!

Is DECUS now COMPAQUS?  :-)  Just doesn't have the same ring to it...

Matt

Re: Gnat on OpenVMS

[Robert Dewar]

In article <FC98rC.n4p@news.boeing.com>,
  nickerson@pundit.ds.boeing.com () wrote:
> actually "it is definitely true" is NOT a true statement; it
> is your reading of the tea leaves

I am not sure what tea leaves means here. I am referring to
several customers of ours who have expressed that opinion.
These are also customers who appreciate the fact that you
do NOT have to use the VMS style DCL commands to run GNAT,
but can in fact use something similar to the standard Unix
commands.

; counterexample - I also
> program
> on DUX (Digital UNIX - now Compaq's Tru64 unix), and on that
> platform I prefer the "native debugger" ladebug and not GDB;
> again that is because of the usability of ladebug (hint: it
> looks a lot like VMSdebugger to me) and my lack of expertise
> with GDB;

Well I am not sure that Alpha/VMS vs Alpha/Tru64 Unix was what
I had in mind when I talked about multi-platform development.
it is hardly surprising that ladebug might have some
similarities to VMS debug. Indeed what you say here really
strengthens my point. If you are working on multiple targets,
you prefer tools that work the same on all targets. I am afraid
that by no stretch of the imagination does VMS debug meet this
criterion, and I am afraid that you will NOT find a debugger
you like on many targets (indeed on such targets as VxWorks,
the only game in town is GDB, since Wind River, has standardized
on GDB, a decision that will be followed by a number of large
players in the near future.

Robert Dewar
Ada Core Technologies


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

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <FC99Mz.5up@news.boeing.com>, nickerson@pundit.ds.boeing.com () writes:
> 
> In article <7i98hl$d8a$1@nnrp1.deja.com>, 
> Robert Dewar <robert_dewar@my-dejanews.com> writes:

> |>  2. In particular, there was no possibility of finding
> |>     resources at Digital for Ada 95 specific modifications
> |>     to the VMS debugger (remember that Digital's first
> |>     inclination was to completely abandon Ada on VMS and
> |>     push all their customers to DEC Unix, it was only when
> |>     a number of customers notified Digital that this was
> |>     not acceptable, that some attention was given to Ada 95
> |>     on VMS.
> 
> I am unable to rationally comment on Digital's eratic behaviors;

It is good to remember that at the time this contract was drawn up
support for the VMS debugger was rather far from support for the
DEC Ada compiler (and presumably from the DEC folk arranging the
contract with ACT) within the DEC organization.  Viewed from that
standpoint, VMS debugger changes may have been _considerably_ more
difficult than the technical issues would be alone.  So while from
the outside you may see irrational behavior, at the time and in that
place it may have been quite reasonable for DEC to approach it that way.

Note that implementing the contract took considerably longer
than it took DEC to rearrange their internal organization, but
the standards for correctness of a compiler are somewhat more
rigid :-).

> |>  3. Adapting GNAT to use the VMS debugger would have been a
> |>     major work item. Would it have been more expensive than
> |>     adapting GDB? Probably, but who knows, we were never asked
> |>     to bid on that adaptation.
> 
> yes DEC made a $ decision; it was the wrong decision;

DEC made the wrong decision for my business interests.  That is
quite different from saying that they made the wrong decision
for _their_ business interests.  VMS folk and Ada folk should
be quite accustomed to decisions being made that do not favor
what they see as superior technology.

Then again, I don't think Ada advocates should wish for those
lightening bolts from the blue like Microsoft deciding to implement
Windows 2002 in Ada, because certainly they would call it A++ in
order to justify certain important syntax changes preserving
their freedom to "innovate".

> |>Yes, there will be some people who always will prefer the VMS
> |>debugger, and just as no amount of improvement to VI will woo
> |>away EMACS users, I am sure they will feel that way
> |>indefinitely. But in the long run, we are confident that VMS
> |>Ada users will find that GDB meets their requirements, and
> |>indeed a number of users are finding that it works fine for
> |>them right now.
> 
> the native editor of VMS is the TPU editor; given that I started
> with VMS when edt was native that is the keypad of choice; neither 
> VI nor EMACS are on the event horizon for me - I'd go with NEDIT;
> I have heard of EMACS with edt keypad but there again even the look
> of EMACS puts me off;

You may have chosen that newfangled TPU editor, but for me the native
editor of VMS is TECO, since it was there from the initial release
(and already familiar).  So being in the minority (but technically
superior, as I see it) in the editor realm too, I have perspective
on the other areas where I do not get what I want on the first go-round.

> I understand the lack of resources; but I continue to believe that
> GDB is the wrong direction on VMS; 

GDB may be the wrong choice for the existing VMS customer base, but
it may be the right choice for GNAT in general and even for VMS in
terms of attracting new users.  If VMS dreams of Galaxy dominance
should come to pass, there will be people who want to port previously
non-VMS software to VMS, and if they are accustomed to GDB elsewhere
finding an "old friend" (not mine, but perhaps theirs) will speed them
along.  Finding Ada should help them on the portability front as well.
I recently had a look at some Ada software from a non-DEC Unix system
for looking at the feasibility of porting it to VMS.  The response
I gave was that it was highly viable to use the DEC Ada (83) compiler
for this project, since only two out of several hundred modules were
not readily portable (without even a description of what the software
does).

If that had been Ada95 code, there would be no chance without an
Ada95 compiler, and having a compiler would be much more important
than having the best debugger.

I do not view the current GNAT situation as necessarily being the
last chance to debug Ada95 on VMS, but certainly an important milestone.

Larry Kilgallen

Re: Gnat on OpenVMS

[Larry Kilgallen]

In article <FC9A9F.A48@news.boeing.com>, nickerson@mirage.boeing.com () writes:
> 
> In article <7i6a5g$hjq$1@nnrp1.deja.com>, 
> Robert Dewar <robert_dewar@my-dejanews.com> writes:
> 
> |>Well sure, if DEC had been willing to invest the resources to
> |>update the VMS debugger, not only with respect to Ada 95, but
> |>also with respect to other shortcomings (e.g. lack of
> |>scalability to the multi-processing environment), then that
> |>would have been fine. But given that this was not going to
> |>happen (not just for $$$ reason but for many other reasons),
> |>it was not a viable route.
> 
> am not familiar with limitations or the internals involved; my
> understanding would be that there is a basic debug engine and it
> is coupled with each specific, supported language's "module" for
> expression evalutation & whatnot; could you give a critique of
> the shortcomings as you see them;

Those language modules, however, can only be inserted when the
debugger is built, rather than being inserted by an add-on like
GNAT.  But DEC has a history of fixing such flexibility gaps,
and it could be that in the future they will be motivated to
do so.  Talking to them at the US DECUS Symposium in Providence
next month would certainly help.  That doesn't mean you get the
flexibility you want in the very next release, but DEC does listen
and address such things in the longer term.  I have been told that
they will be addressing one of my requests (unrelated to Ada) that
was made 18 years ago :-).

Larry Kilgallen

Re: Gnat on OpenVMS

[Thierry Lelegard]

> ..., and having a compiler would be much more important
> than having the best debugger.

Two points I would like to comment:
1. compiler more important than debugger
2. best debugger

1. I think that the compiler and the debugger are (almost)
equally important. Once an application is written by the
average human programmer, it usually does not work (and
PLEASE do not tell me that this not true with Ada, I have
seen horrible things in Ada due to horrible programmers).

So, you need to debug it. A very good language and a brilliant
compiler may be nice for university courses but, in the
industry, this is NUTS without a debugger.

We need the complete chain:
- source control / change management / configuration control
- editor
- compiler
- linker
- debugger
- profiler
- run-time analyzer
- crash dump analyzer

On OpenVMS, this chain is very consistent. Move from C++
to Ada (DEC Ada), you will only swap the compiler and
keep all other tools.

The problem with GNAT on OpenVMS is that it is not an
insertion in the chain (compiler replacement), it imposes
to change all the following tools in the chain. You can
only keep the previous tools (source processing).

2. "Best" debugger: I do not ask for the BEST debugger but
only for a WORKING one. And, currently, GDB is clearly not
a working tool on VMS. I sincerely hope that it will be
improved to a usable level (and, why not, to the level of
excellence). But, unless I receive evidence of the contrary,
I do not believe AT ALL that any large industrial project
has been debugged on OpenVMS with GNAT/GDB.

-Thierry
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: Gnat on OpenVMS

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]


Thierry Lelegard <lelegard@club-internet.fr> a �crit dans le message :
7if0bu$mph$1@front5.grolier.fr...
> > ..., and having a compiler would be much more important
> > than having the best debugger.
>
> Two points I would like to comment:
> 1. compiler more important than debugger
> 2. best debugger
>
> 1. I think that the compiler and the debugger are (almost)
> equally important. Once an application is written by the
> average human programmer, it usually does not work (and
> PLEASE do not tell me that this not true with Ada, I have
> seen horrible things in Ada due to horrible programmers).

So, what about fixing the programmers ? :-)

But don't hold you breath, GDB wont be able to debug programmers
for at least one more century :-)

Pascal.