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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-26 05:28:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!nntp-relay.ihug.net!ihug.co.nz!west.cox.net!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Getting a symbol table from Gnat 3.15p on Windows Date: Wed, 26 Feb 2003 08:27:35 -0500 Organization: MindSpring Enterprises Message-ID: References: <8_O5a.198854$iG3.23506@sccrnsc02> NNTP-Posting-Host: d1.56.bd.1c X-Server-Date: 26 Feb 2003 13:29:03 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:34604 Date: 2003-02-26T13:29:03+00:00 List-Id: Randy Brukardt wrote in message news:v5o5r163lk686d@corp.supernews.com... > > 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.) > Well, I get it out of the XD-Ada compiler now after it has linked an image -at what precise phase that occurs I do not know, so one might debate that it doesn't happen at link time. But this is also something that targets an embedded computer, so it probably does things very differently than your garden variety workstation compiler. You don't put symbols into the linked image - or anything else that doesn't need to be there. Its also working with fixed addresses, so that probably changes the equation as well. > 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. > Well, "debugger" if you will. A rose by any other name still won't make very good soup. :-) If peeking and poking addresses is the definition of a "debugger" then its a "debugger". However it isn't used (primarily, at least) to remove bugs. Its used more as a kind of I/O mechanism when you don't have sensors & actuators generating electrical inputs & outputs so you can run simulated data through the code. Since its got to grind through *lots* of data, its not really doing the same thing as what one might typically call a "debugger". > 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. > Yeah, see, here's the problem. It *is* a kind of "command line debugger" at least in terms of complexity, but its job is not to do debugging. Its job is to run test cases through a simulated control system and possibly to interact with other models to connect the control to those models. I'm trying to work with an embedded program wherein I hope to wrap enough code around it to make it *think* its in its embedded environment while remaining mostly undisturbed. If I start injecting too much other stuff into the code, it defeats the whole purpose because you'll have to start modifying more and more the part you're lifting out of the embedded world. Since it isn't doing a job involving some person typing a value for a variable, setting a breakpoint and running, then looking at a result, we're not talking about something where time is of no concern. Its got to churn through lots of simulated data points, if not in real time, at least pretty darned fast or it may not deliver acceptable performance and may not be able to utilize the other simulations. > > 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. :-) > Yes, we do control the load addresses of things. You've got to when you're building something embedded because typically the address space is mapped to different kinds of uses. So what you're saying is that whatever addresses are being dumped out by nm and/or objdump are basically useless because to read them in and somehow try to use 'Address to get at the contents of that location isn't going to work? If that's the case, then I understand how it isn't going to work as conceived. My existing on-board monitor isn't going to be able to extract information from the image as it exists, which means some serious modification to what is there now - or at least dangling something off on the side that may or may not work in the same manner. I guess its going to require more thought..... MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ======================================================================