* Gnat on OpenVMS @ 1999-05-18 0:00 Thierry Lelegard 1999-05-18 0:00 ` Larry Kilgallen ` (4 more replies) 0 siblings, 5 replies; 34+ messages in thread From: Thierry Lelegard @ 1999-05-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard @ 1999-05-18 0:00 ` Larry Kilgallen 1999-05-19 0:00 ` Robert Dewar 1999-05-19 0:00 ` Gautier 1999-05-19 0:00 ` Robert Dewar ` (3 subsequent siblings) 4 siblings, 2 replies; 34+ messages in thread From: Larry Kilgallen @ 1999-05-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 ` Larry Kilgallen @ 1999-05-19 0:00 ` Robert Dewar 1999-05-19 0:00 ` Gautier 1 sibling, 0 replies; 34+ messages in thread From: Robert Dewar @ 1999-05-19 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 ` Larry Kilgallen 1999-05-19 0:00 ` Robert Dewar @ 1999-05-19 0:00 ` Gautier 1 sibling, 0 replies; 34+ messages in thread From: Gautier @ 1999-05-19 0:00 UTC (permalink / raw) > 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/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard 1999-05-18 0:00 ` Larry Kilgallen @ 1999-05-19 0:00 ` Robert Dewar 1999-05-19 0:00 ` Daniel Thonon ` (2 subsequent siblings) 4 siblings, 0 replies; 34+ messages in thread From: Robert Dewar @ 1999-05-19 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard 1999-05-18 0:00 ` Larry Kilgallen 1999-05-19 0:00 ` Robert Dewar @ 1999-05-19 0:00 ` Daniel Thonon 1999-05-19 0:00 ` Thierry Lelegard 1999-05-19 0:00 ` Robert Dewar 1999-05-21 0:00 ` nickerson 4 siblings, 1 reply; 34+ messages in thread From: Daniel Thonon @ 1999-05-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-19 0:00 ` Daniel Thonon @ 1999-05-19 0:00 ` Thierry Lelegard 1999-05-19 0:00 ` Larry Kilgallen 1999-05-20 0:00 ` Robert Dewar 0 siblings, 2 replies; 34+ messages in thread From: Thierry Lelegard @ 1999-05-19 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-19 0:00 ` Thierry Lelegard @ 1999-05-19 0:00 ` Larry Kilgallen 1999-05-20 0:00 ` Robert Dewar 1999-05-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 34+ messages in thread From: Larry Kilgallen @ 1999-05-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-19 0:00 ` Larry Kilgallen @ 1999-05-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 34+ messages in thread From: Robert Dewar @ 1999-05-20 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-19 0:00 ` Thierry Lelegard 1999-05-19 0:00 ` Larry Kilgallen @ 1999-05-20 0:00 ` Robert Dewar 1999-05-21 0:00 ` Daniel Thonon 1 sibling, 1 reply; 34+ messages in thread From: Robert Dewar @ 1999-05-20 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-20 0:00 ` Robert Dewar @ 1999-05-21 0:00 ` Daniel Thonon 1999-05-21 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 34+ messages in thread From: Daniel Thonon @ 1999-05-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-21 0:00 ` Daniel Thonon @ 1999-05-21 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 34+ messages in thread From: Larry Kilgallen @ 1999-05-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard ` (2 preceding siblings ...) 1999-05-19 0:00 ` Daniel Thonon @ 1999-05-19 0:00 ` Robert Dewar 1999-05-21 0:00 ` nickerson 1999-05-21 0:00 ` nickerson 4 siblings, 1 reply; 34+ messages in thread From: Robert Dewar @ 1999-05-19 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-19 0:00 ` Robert Dewar @ 1999-05-21 0:00 ` nickerson 1999-05-22 0:00 ` Larry Kilgallen 1999-05-22 0:00 ` Robert Dewar 0 siblings, 2 replies; 34+ messages in thread From: nickerson @ 1999-05-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-21 0:00 ` nickerson @ 1999-05-22 0:00 ` Larry Kilgallen 1999-05-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 34+ messages in thread From: Larry Kilgallen @ 1999-05-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-21 0:00 ` nickerson 1999-05-22 0:00 ` Larry Kilgallen @ 1999-05-22 0:00 ` Robert Dewar 1999-05-24 0:00 ` nickerson 1 sibling, 1 reply; 34+ messages in thread From: Robert Dewar @ 1999-05-22 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-22 0:00 ` Robert Dewar @ 1999-05-24 0:00 ` nickerson 1999-05-24 0:00 ` Robert Dewar 1999-05-25 0:00 ` Larry Kilgallen 0 siblings, 2 replies; 34+ messages in thread From: nickerson @ 1999-05-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-24 0:00 ` nickerson @ 1999-05-24 0:00 ` Robert Dewar 1999-05-25 0:00 ` Larry Kilgallen 1 sibling, 0 replies; 34+ messages in thread From: Robert Dewar @ 1999-05-24 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-24 0:00 ` nickerson 1999-05-24 0:00 ` Robert Dewar @ 1999-05-25 0:00 ` Larry Kilgallen 1 sibling, 0 replies; 34+ messages in thread From: Larry Kilgallen @ 1999-05-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard ` (3 preceding siblings ...) 1999-05-19 0:00 ` Robert Dewar @ 1999-05-21 0:00 ` nickerson 1999-05-22 0:00 ` Robert Dewar 4 siblings, 1 reply; 34+ messages in thread From: nickerson @ 1999-05-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-21 0:00 ` nickerson @ 1999-05-22 0:00 ` Robert Dewar 1999-05-22 0:00 ` Thierry Lelegard 0 siblings, 1 reply; 34+ messages in thread From: Robert Dewar @ 1999-05-22 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-22 0:00 ` Robert Dewar @ 1999-05-22 0:00 ` Thierry Lelegard 1999-05-22 0:00 ` Larry Kilgallen 1999-05-22 0:00 ` Robert Dewar 0 siblings, 2 replies; 34+ messages in thread From: Thierry Lelegard @ 1999-05-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-22 0:00 ` Thierry Lelegard @ 1999-05-22 0:00 ` Larry Kilgallen 1999-05-23 0:00 ` Robert Dewar 1999-05-23 0:00 ` Robert Dewar 1999-05-22 0:00 ` Robert Dewar 1 sibling, 2 replies; 34+ messages in thread From: Larry Kilgallen @ 1999-05-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-22 0:00 ` Larry Kilgallen @ 1999-05-23 0:00 ` Robert Dewar 1999-05-24 0:00 ` nickerson 1999-05-23 0:00 ` Robert Dewar 1 sibling, 1 reply; 34+ messages in thread From: Robert Dewar @ 1999-05-23 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-23 0:00 ` Robert Dewar @ 1999-05-24 0:00 ` nickerson 1999-05-24 0:00 ` Mike 1999-05-25 0:00 ` Larry Kilgallen 0 siblings, 2 replies; 34+ messages in thread From: nickerson @ 1999-05-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-24 0:00 ` nickerson @ 1999-05-24 0:00 ` Mike 1999-05-25 0:00 ` Matthew Whiting 1999-05-25 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 34+ messages in thread From: Mike @ 1999-05-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-24 0:00 ` Mike @ 1999-05-25 0:00 ` Matthew Whiting 0 siblings, 0 replies; 34+ messages in thread From: Matthew Whiting @ 1999-05-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-24 0:00 ` nickerson 1999-05-24 0:00 ` Mike @ 1999-05-25 0:00 ` Larry Kilgallen 1999-05-25 0:00 ` Thierry Lelegard 1 sibling, 1 reply; 34+ messages in thread From: Larry Kilgallen @ 1999-05-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-25 0:00 ` Larry Kilgallen @ 1999-05-25 0:00 ` Thierry Lelegard 1999-05-27 0:00 ` Pascal Obry 0 siblings, 1 reply; 34+ messages in thread From: Thierry Lelegard @ 1999-05-25 0:00 UTC (permalink / raw) > ..., 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-25 0:00 ` Thierry Lelegard @ 1999-05-27 0:00 ` Pascal Obry 0 siblings, 0 replies; 34+ messages in thread From: Pascal Obry @ 1999-05-27 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-22 0:00 ` Larry Kilgallen 1999-05-23 0:00 ` Robert Dewar @ 1999-05-23 0:00 ` Robert Dewar 1999-05-24 0:00 ` nickerson 1 sibling, 1 reply; 34+ messages in thread From: Robert Dewar @ 1999-05-23 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-23 0:00 ` Robert Dewar @ 1999-05-24 0:00 ` nickerson 1999-05-25 0:00 ` Robert Dewar 0 siblings, 1 reply; 34+ messages in thread From: nickerson @ 1999-05-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-24 0:00 ` nickerson @ 1999-05-25 0:00 ` Robert Dewar 0 siblings, 0 replies; 34+ messages in thread From: Robert Dewar @ 1999-05-25 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Gnat on OpenVMS 1999-05-22 0:00 ` Thierry Lelegard 1999-05-22 0:00 ` Larry Kilgallen @ 1999-05-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 34+ messages in thread From: Robert Dewar @ 1999-05-22 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~1999-05-27 0:00 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard 1999-05-18 0:00 ` Larry Kilgallen 1999-05-19 0:00 ` Robert Dewar 1999-05-19 0:00 ` Gautier 1999-05-19 0:00 ` Robert Dewar 1999-05-19 0:00 ` Daniel Thonon 1999-05-19 0:00 ` Thierry Lelegard 1999-05-19 0:00 ` Larry Kilgallen 1999-05-20 0:00 ` Robert Dewar 1999-05-20 0:00 ` Robert Dewar 1999-05-21 0:00 ` Daniel Thonon 1999-05-21 0:00 ` Larry Kilgallen 1999-05-19 0:00 ` Robert Dewar 1999-05-21 0:00 ` nickerson 1999-05-22 0:00 ` Larry Kilgallen 1999-05-22 0:00 ` Robert Dewar 1999-05-24 0:00 ` nickerson 1999-05-24 0:00 ` Robert Dewar 1999-05-25 0:00 ` Larry Kilgallen 1999-05-21 0:00 ` nickerson 1999-05-22 0:00 ` Robert Dewar 1999-05-22 0:00 ` Thierry Lelegard 1999-05-22 0:00 ` Larry Kilgallen 1999-05-23 0:00 ` Robert Dewar 1999-05-24 0:00 ` nickerson 1999-05-24 0:00 ` Mike 1999-05-25 0:00 ` Matthew Whiting 1999-05-25 0:00 ` Larry Kilgallen 1999-05-25 0:00 ` Thierry Lelegard 1999-05-27 0:00 ` Pascal Obry 1999-05-23 0:00 ` Robert Dewar 1999-05-24 0:00 ` nickerson 1999-05-25 0:00 ` Robert Dewar 1999-05-22 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox