Re: Getting a symbol table from Gnat 3.15p on Windows

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

Randy Brukardt <randy@rrsoftware.com> 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
======================================================================