From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31b8879c52cdbc65 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Gnat on OpenVMS Date: 1999/05/22 Message-ID: <7i6aur$i1g$1@nnrp1.deja.com>#1/1 X-Deja-AN: 480836293 References: <7hshfq$5tc$1@front1.grolier.fr> X-Http-Proxy: 1.0 x31.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Sat May 22 13:20:27 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-05-22T00:00:00+00:00 List-Id: In article , 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.---