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=0.1 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cdaa3abe008a8f57 X-Google-Attributes: gid103376,public From: Sam Carnicelli Subject: Re: Ada Type Information Date: 1999/03/08 Message-ID: <36E409E3.20F5ED75@lmco.com>#1/1 X-Deja-AN: 452634843 Content-Transfer-Encoding: 7bit References: <36E03843.3AD74457@lmco.com> <7bpk2g$eun$1@nnrp1.dejanews.com> <36E3D3A6.6BAFA0DC@lmco.com> <7c0rvn$7os$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Lockheed Martin OR&SS Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-03-08T00:00:00+00:00 List-Id: dennison@telepath.com wrote: > > > > > This is why I want to get the information from a product of the > > compiler. If a new > > compiler were to change the layout of the record type, I would simply > > have to rerun my tool to get the new information. All of the methods I > > have mentioned make use of products of the compiler. > > Typically the only part of a compilation environemnt that keeps this kind of > information it the debugging support. > > We had a situation here where we basicly needed a mini-debugging capability > in our simulator's Instructor Operator Station. So the engineers here > reverse-engineered the debug information created by the compiler. That > solution seemed quite dangerous to me, as a compiler vendor has every reason > to believe they can change the format of that data at will (as long as they > change their debuggers to match). But such a change would require us to redo > the entire reverse-engineering process (or more likely, refuse to ever > upgrade our compiler). In the end, they were convinced to not do this (at > least on this program). > > But if you stick to GCC technology, there's probably some standard for the > "-g" output. Perhaps there's even a document somewhere describing it for > prospective debugger writers. This might be a reasonable option, assuming you > are willing to keep up with any changes the gcc folks put in. > > T.E.D. What you are describing is similar to the stabs data produced by the gcc compiler with the -g and -S options. It is described as a debug format and seems to be somewhat of a standard. It appears to have everything I would need, but the syntax is not intuitive. Apparently, the version used under Solaris has some extensions and I can't find adequate documentation. This data is actually used by the gdb debugger.... ------------------------------------------------------------------ Sam Carnicelli Lockheed Martin Phone : 315-456-2881 Syracuse, NY 13221-4840 Fax : 315-456-0107 e-mail: samuel.charles.carnicelli@lmco.com ------------------------------------------------------------------