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

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

Its pretty much as you describe. We've got various packages that contain
global data. The embedded, on-board monitor can read and write any addresses
in memory, so we have an external system that feeds it data & addresses to
plug & chug. (It does this across a 1553, but could be modified to use
Ethernet, etc.) The monitor and its external counterpart *can* be used for
debugging, but its more important use is to plug test data into input memory
locations, let the software crank and get the outputs from other memory
locations. It does this at a high rate of speed so that it doesn't interfere
with the realtime control and it is used to test the control's reaction to
dynamic events. (Temperatures & pressures changing, actuator positions
moving, etc.)

Low level software in the embedded system is doing the A/D and D/A
conversions & actual I/O. To drag this over to a workstation, you'd
basically have to dummy-up the low level I/O and have something cycle the
software. (Can't tie to an interrupt like we do on the embedded box - or
maybe you could, but it starts getting complicated.) From there, if I can
change the pipeline that feeds the monitor and get a symbol table that the
external software can use, basically, I can run all the test scenarios that
are already built for the embedded machine. In addition, I can rig up code
to connect various other systems like engine models and actuator models to
the control system, so long as I can feed it data fast enough. If I have a
fast enough machine, I might even be able to run the control in realtime -
which has distinct advantages.

The thing is, if I start coming up with something that requires too much
modification of the control software or starts linking together too many
other pieces that might introduce time delays or allow the project to get
too big in scope, it isn't going to fly. So I'm trying to see if I can get a
usable symbol table that could be fed to my existing external monitor
program that would result in addresses that the internal monitor program can
use to access global data and thus have a relatively simple answer for how
to run the embedded software on a workstation. Unfortunately, it is
appearing that whatever addresses I might be able to come up with are not
going to be usable by the internal monitor as it exists. From there, its a
matter of determining how much additional work and complexity and time
penalty would be involved in cobbling together some other answer. Contrary
to the perception of many, we don't have billions to throw away on
developing anything we like so I've got to do this in a fairly small number
of $$$ or it won't be feasable.

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
======================================================================

<tmoran@acm.org> wrote in message
news:9q77a.270939$HN5.1154712@rwcrnsc51.ops.asp.att.net...
>   I gather these aren't for memory mapped IO ports?  Does your program
> under test just have a collection of things like
>   Voltage : Integer_8; -- etc
> that you want to examine/modify from a second program/task?  It sounds
> like you essentially want to put those variables in a place in memory
> where they can be accessed from either testee or tester.  Are the
> variables of interest sprinkled about, or are they in a few clumps?  Can
> you put them in a shared passive partition and have another parition be
> the examiner/modifier?  Or can you tell your linker to put those clumps,
> or at least the packages containing them, at set locations in sharable
> memory?  Using a symbol table of course lets you leave the items of
> interest wherever the linker put them, but perhaps you can instead move
> the items to a more convenient spot - without significant change to the
> program under test.