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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6403691d6db186c8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-25 17:24:49 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Getting a symbol table from Gnat 3.15p on Windows Date: Tue, 25 Feb 2003 19:26:53 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <8_O5a.198854$iG3.23506@sccrnsc02> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:34588 Date: 2003-02-25T19:26:53-06:00 List-Id: Marin David Condic wrote in message ... >Found it and tried it out. You're right about the lack of type info. I >didn't look closely enough to determine if nm would tell you how big >something was. That would at least allow you to find it in memory and >extract or write to it. But without the type info, the game is basically >over. You've got to know how to interpret the data, not just read and write >to it. A look at the names suggests that one might be able to parse them >backwards into Ada-ish names without too much trouble, but one would worry >about finding exceptions or things that otherwise won't go backwards easily. > >Too bad Gnat doesn't seem to dump its symbol tables in a readily accessible >manner. I suppose one might be able to cobble something together with nm, >objdump, ASIS and several yards of glue code, but its suggesting that one >would spend all of one's time re-developing a compiler/linker rather than >the app of interest. Maybe there's another route. I'll have to keep >investigating... Raw linker symbols is not what you need. You need the debugger's information map. I'm not aware of any compiler on any platform that dumps that information at link time. (Sometimes, you can find a tool to dump it from the object code, but that is not part of the linker.) In any case, as I said, what you're writing is a debugger. Not a conventional debugger, of course, but to find out what locations and types to read and write is precisely (and just about all) of what a debugger does. You're welcome to call it something else, but that's what it is. You've said that you have memory read and write interfacing. That's what the debugger interface in Windows provides. But you still need the entire infastructure on top of that to figure out where things are. So, you're essentially looking at a program the complexity of a command-line debugger. For Janus/Ada, we have to take the symbol table information (produced by the compiler), and combine and remap it at bind time, producing a debugger file containing all of the Ada information. We also inject some special linker symbols into the object code. The Microsoft linker then creates the final execuable. When the debugger runs, we extract the address of the special linker symbols, then add that appropriately to the debugger information file. Then we can access objects as needed. In your case, you probably can control the load address of things, so you probably can use a constant rather than having to extract load addresses at runtime. But you still have al of the other calculations. (And, if anything you need to look at is a local variable or is accessed through an access object, the addressing has to be completely done at runtime. Just like a debugger. :-) Randy.