Getting a symbol table from Gnat 3.15p on Windows

Getting a symbol table from Gnat 3.15p on Windows

[Marin David Condic]

I've got an application I'm investigating that looks something like a
debugger. What I think I need is some means of getting the addresses of data
items from a linked image such that I can interrogate the image for data
values and set the contents of variables as needed. Basically one app will
communicate with the other, knowing the other apps symbol table. Here's the
question(s):

Is there a means of getting a symbol table for an app that is compiled &
linked with Gnat 3.15p on Windows? What switches or secret handshakes are
needed to get that to happen? (We can worry about formats, etc. at a later
point - right now I need to know if it is possible and how to make it happen
to demonstrate proof of concept.) Also, would there be any obvious problems
with passing an address into an app and having it interrogate its own memory
using a variable of type Address? (Such as different address formats from
the data in the symbol table or OS related memory restrictions.)

If this doesn't happen readily with Gnat/Windows, I can consider other
environments such as a different compiler or platform so long as it doesn't
get too far afield from a workstation & easily obtainable software. I've
already got something like this using an old XD-Ada compiler targeting an
embedded processor & I want to build something similar to run the embedded
code on a workstation. Any ideas or help would be appreciated.

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

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

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Marin David Condic" <mcondic.auntie.spam@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: February 20, 2003 7:24 AM
Subject: Getting a symbol table from Gnat 3.15p on Windows


> I've got an application I'm investigating that looks something like a
> debugger. What I think I need is some means of getting the addresses of data
> items from a linked image such that I can interrogate the image for data
> values and set the contents of variables as needed. Basically one app will
> communicate with the other, knowing the other apps symbol table. Here's the
> question(s):
> 
> Is there a means of getting a symbol table for an app that is compiled &
> linked with Gnat 3.15p on Windows? What switches or secret handshakes are
> needed to get that to happen? (We can worry about formats, etc. at a later
> point - right now I need to know if it is possible and how to make it happen
> to demonstrate proof of concept.)
Have you tried the "secret handshake" given in Section 5.1 of the GNAT
User's Guide?

 Also, would there be any obvious problems
> with passing an address into an app and having it interrogate its own memory
> using a variable of type Address? (Such as different address formats from
> the data in the symbol table or OS related memory restrictions.)
I don't see any problem if all you want to do is "interrogate."  Attempting
to write, however, is another matter, as some of the app's memory is sure
to be "read only."

> 
> If this doesn't happen readily with Gnat/Windows, I can consider other
> environments such as a different compiler or platform so long as it doesn't
> get too far afield from a workstation & easily obtainable software. I've
> already got something like this using an old XD-Ada compiler targeting an
> embedded processor & I want to build something similar to run the embedded
> code on a workstation. Any ideas or help would be appreciated.
> 
> 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
> ======================================================================
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

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

[Stephen Leake]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> I've got an application I'm investigating that looks something like a
> debugger. What I think I need is some means of getting the addresses of data
> items from a linked image such that I can interrogate the image for data
> values and set the contents of variables as needed. Basically one app will
> communicate with the other, knowing the other apps symbol table. Here's the
> question(s):
> 
> Is there a means of getting a symbol table for an app that is compiled &
> linked with Gnat 3.15p on Windows? 

the gnu linker 'ld' will dump a file containing the symbol table; see
http://www.gnu.org/manual/ld-2.9.1/ld.html

Note you can pass 'ld' options to gnatmake via -largs.

But I think you mean you want to do this via an API, not a command
line tool.

In that case, you need to include some of the linker code in your
program. That is possible; the linker code is written as a set of
libraries providing access to object files. See the sources for
binutils. 

> What switches or secret handshakes are needed to get that to happen?
> (We can worry about formats, etc. at a later point - right now I
> need to know if it is possible and how to make it happen to
> demonstrate proof of concept.) 

Trivial for command line, some work required for API access.

> Also, would there be any obvious problems with passing an address
> into an app and having it interrogate its own memory using a
> variable of type Address? (Such as different address formats from
> the data in the symbol table or OS related memory restrictions.)

Different object file formats have different meanings for "address".
But the gnu linker provides a way to get the "process virtual address"
(my name, not the Gnu name), which is what 'address gives.

As long as the address is not supposed to have physical meaning (ie,
this is the serial port command register), you should have no problem.

> If this doesn't happen readily with Gnat/Windows, I can consider
> other environments such as a different compiler or platform so long
> as it doesn't get too far afield from a workstation & easily
> obtainable software. 

It's not the OS, it's the linker and object file format.

-- 
-- Stephe

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

[Marin David Condic]

David C. Hoos, Sr. <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.29.1045754029.9948.comp.lang.ada@ada.eu.org...
> Have you tried the "secret handshake" given in Section 5.1 of the GNAT
> User's Guide?
>
I try not to read documentation if I can get someone to do it for me. I'm in
management now. :-) But thanks for pointing me at 5.1 - I'll take a glance
and see if it answers the questions.


> I don't see any problem if all you want to do is "interrogate."
Attempting
> to write, however, is another matter, as some of the app's memory is sure
> to be "read only."
>
Nope. Gotta be able to write to addresses. Its a matter of being able to set
up test cases that deposit data, cycle the code, collect results and return
them to the other app. If I can't do this, its a non-starter. If the
restriction is only on some "special" addresses, maybe we can live with
that.

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

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

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Marin David Condic" <mcondic.auntie.spam@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: February 20, 2003 8:16 PM
Subject: Re: Getting a symbol table from Gnat 3.15p on Windows


> David C. Hoos, Sr. <david.c.hoos.sr@ada95.com> wrote in message
> news:mailman.29.1045754029.9948.comp.lang.ada@ada.eu.org...
> > Have you tried the "secret handshake" given in Section 5.1 of the GNAT
> > User's Guide?
> >
> I try not to read documentation if I can get someone to do it for me. I'm in
> management now. :-) But thanks for pointing me at 5.1 - I'll take a glance
> and see if it answers the questions.
> 
> 
> > I don't see any problem if all you want to do is "interrogate."
> Attempting
> > to write, however, is another matter, as some of the app's memory is sure
> > to be "read only."
> >
> Nope. Gotta be able to write to addresses. Its a matter of being able to set
> up test cases that deposit data, cycle the code, collect results and return
> them to the other app. If I can't do this, its a non-starter. If the
> restriction is only on some "special" addresses, maybe we can live with
> that.
The restricted addresses would be the code space and read-only data -- e.g.,
constant data storage.  Variables would not be retstricted.
> 
> 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
> ======================================================================
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

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

[Marin David Condic]

Stephen Leake <Stephen.A.Leake@nasa.gov> wrote in message
news:ulm0als83.fsf@nasa.gov...
>
> the gnu linker 'ld' will dump a file containing the symbol table; see
> http://www.gnu.org/manual/ld-2.9.1/ld.html
>
Thanks for the pointer. I'll take a look - although I am loathe to RTFM. :-)

BTW I'm not sure if this is Linux, or gnu specific - does it come as the
"standard" linker with the Gnat Windows distribution? I thought it used the
Windows linker. The rules may change there.


> Note you can pass 'ld' options to gnatmake via -largs.
>
I knew about the largs. I was really hoping someone out there would say
"Hey, Marin, its intuitively obvious to even the most casual observer that
all you have to do is type 'gnatmake something -largs<someswitches>' and
viola - you get a symbol table in XXX format!"


> But I think you mean you want to do this via an API, not a command
> line tool.
>
Not really. I want to take some batch of wrapper code and compile it with a
bunch of application code and get a symbol table. Command line is fine for
that. Once you have that in hand, you feed it to another program that uses
the symbol table to interrogate and write to balues in the wrapper/app image
you built. Clear as mud? I thought so. :-)



> In that case, you need to include some of the linker code in your
> program. That is possible; the linker code is written as a set of
> libraries providing access to object files. See the sources for
> binutils.
>
Why? Maybe a pragma to pass something to the linker, O.K. But what else is
needed except the object files that the linker is going to build into an
image. I don't need anything magic - just the addresses at which the linker
put stuff.


>
> Trivial for command line, some work required for API access.
>
Not sure why you've got some kind of distinction going here. If you link
program X, the linker has to put variables and stuff at specific addresses
(relative to virtual address space, maybe, but that's it) All I need is a
symbol table that tells me where variables were located in such a way that
given the addresses, I can interrogate & write to those addresses via a
second app communicating with my wrapper code. Is there something I'm
missing?




>
> Different object file formats have different meanings for "address".
> But the gnu linker provides a way to get the "process virtual address"
> (my name, not the Gnu name), which is what 'address gives.
>
> As long as the address is not supposed to have physical meaning (ie,
> this is the serial port command register), you should have no problem.
>
No - just so long as the image that produced the symbol table would
recognize the number and be able to store & fetch from that address, I'd be
golden.


>
> It's not the OS, it's the linker and object file format.
>
OS's have a nasty habit of trying to save you from yourself. An elephant is
a mouse with an operating system. Not knowing from any technical basis - I
just have a suspicion that if I tried to get the contents of bytes at
"Address X" (where X is a read-in value) the OS may try to "protect" me and
cause trouble. It may or may not be an issue, but I could probably do some
proof-of-concept tests rather quickly if I could get a symbol table out of
an image. Write a "Hello World app that reads in an address and tries to
tell you what is at that location. You get that far and the rest is left as
an exercise for the student. :-)

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

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

[Marin David Condic]

The wierd thing is that you actually might want to write to values in
"constant space" Often you compile with some constants that at run time you
want to "tune" until you figure out what they really ought to be. We tend to
call them "rubber constants". They've got to have the pragma Volatile
applied to them and you've got to be able to plug them in the embedded
system so you can see what it does.

In my current hypothetical app, this might not be a problem since it is
looking at mostly doing testing of logic rather than tuning of constants,
but I'd prefer to be able to zap anything in "data" space.

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

David C. Hoos, Sr. <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.31.1045797779.9948.comp.lang.ada@ada.eu.org...
> The restricted addresses would be the code space and read-only data --
e.g.,
> constant data storage.  Variables would not be retstricted.

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

[sk]

Hi,
mcondic.auntie.spam@acm.org :

 > ...

I cannot speak to windows, but I think that you could probably
find a Linux box if you had to.

1) As "david.c.hoos.sr@ada95.com" suggests (thru RTFM :-), make
a map file.

2) Look at Gnat.Expect and spawn the debugger thru it feeding
commands and reading responses thru scripts based upon the above
map file.

I havn't used Gnat.Expect, but a brief glance suggests that it
might be a reasonable solution (everything about your post
suggests a q&d effort).

-- 
--
-- Merge vertically for real address
--
------------------------------------
-- s n p @ t . o
--  k i e k c c m
------------------------------------

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

[Marin David Condic]

Well, I'm not sure about a map file. I'll have to look at that. It needs to
contain the symbolic names and type information for variables as well as
addresses. If you've got that much out of building the image, then a
solution does exist.

As for the debugger, I doubt that would be of much use. I really think I
need a second image communicating with the system under test and the
presence of the debugger would probably have performance issues, even if I
could find a way of feeding it scripts and getting back the results in some
usable manner. On one level a debugger looks kind of like a similar system -
deposit data in some locations (possibly a fairly large amount of it), turn
the crank on the software some prescribed number of times, then collect the
results (again maybe a fairly large volume of stuff) and put it somewhere
for analysis. But in other respects, it isn't really a debugging job because
it involves simulating the environment the software will see and creating
some unusual kinds of test scenarios. I need to keep the image under test as
simple as possible yet have external to it some fairly sophisticated means
of driving it. Having the image under test fire up the debugger & trying to
utilize that might be simultaneously too much and too little.

If I can figure out how to get the right symbol table info, the rest can be
made to work.

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

sk <sk@noname.com> wrote in message
news:mailman.32.1045809132.9948.comp.lang.ada@ada.eu.org...
>
> I cannot speak to windows, but I think that you could probably
> find a Linux box if you had to.
>
> 1) As "david.c.hoos.sr@ada95.com" suggests (thru RTFM :-), make
> a map file.
>
> 2) Look at Gnat.Expect and spawn the debugger thru it feeding
> commands and reading responses thru scripts based upon the above
> map file.
>
> I havn't used Gnat.Expect, but a brief glance suggests that it
> might be a reasonable solution (everything about your post
> suggests a q&d effort).
>

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

[Stephen Leake]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Stephen Leake <Stephen.A.Leake@nasa.gov> wrote in message
> news:ulm0als83.fsf@nasa.gov...
> >
> > the gnu linker 'ld' will dump a file containing the symbol table; see
> > http://www.gnu.org/manual/ld-2.9.1/ld.html
> >
> Thanks for the pointer. I'll take a look - although I am loathe to RTFM. :-)

Tough. Suck it up!

Seriously, unless you want to pay me, the best I'm willing to do is
say "RTFM" when the manual is clear, available, and accurate.

-- 
-- Stephe

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

[Preben Randhol]

Stephen Leake wrote:
> Seriously, unless you want to pay me, the best I'm willing to do is
> say "RTFM" when the manual is clear, available, and accurate.

So RTFM = Read The Fine Manual here? ;-)

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

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

[Randy Brukardt]

Marin David Condic wrote in message ...
>As for the debugger, I doubt that would be of much use.

If your target is Windows, the only way to do what you want (read and
write another process) is to use the debugger interface. Essentially,
you're writing a debugger. I've done that on Windows, and it isn't fun.

If you were using Janus/Ada, and you asked real nice, I could give you
the code to the debugger, and you'd have everything you need (symbol
table access, debugger engine, etc.). I suppose you might be able to
find similar code for GNAT with some effort (although I suspect you'd
rather use the All-Ada source code of Janus/Ada and JDebug as opposed to
the C (?) source of GDB).

                  Randy.

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

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I suppose you might be able to
> find similar code for GNAT with some effort 

Yes, the GNAT debugger is all GPL; see any Gnu mirror for the binutils
and gdb packages.

> (although I suspect you'd rather use the All-Ada source code of
> Janus/Ada and JDebug as opposed to the C (?) source of GDB).

Definitely. GDB is written in K&R C, to be portable to "any old C
compiler". Really horrible!

-- 
-- Stephe

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

[sk]

Hi,

The Gnat.Expect tools, and I believe the whole Expect
concept, hook into the stdin, stdout and stderr of the
spawned program, Basically, they use the underlying
OS "pipe" mechanisms.

If one were to spawn the debugger, thru expect (or pipes),
and in turn got the debugger to load and run the "image",
the image is as close to production as needed with the
possible exception of extra debugging symbols.

The symbols of interest would be identified by the map
file and the program using Gnat.Expect would tell the
debugger, thru expext calls, to set break-points etc.

<psudo-code>
     Spawn (Debugger);
     ...
     -- Read in all the introduction lines and ignore
     ...
     -- Wait for the Debugger_Stdin to be writeable
     Put_Line (Debugger_Stdin, Load file "image");
     Put_Line (Debugger_Stdin, set break point "image" address);
     ...
     Put_Line (Debugger_Stdin, read address);
     Get_Line (Debugger_Stdout, value at address); -- Really stderr
     ...

Granted the performance would take big hits thru the
debugger, but the "image" is not altered at all.

... since you work for tons of wonderfull tax-dollars (according to
the PBS special) and like "Stephen.A.Leake@nasa.gov", give me the money
and I will show you a full proof-of-concept :-)

... seriously, the map-file, spawn gdb, expect method might be the
closest you get at controlling an "image" without altering the source
or buying sophisticated hardware.

-- 
--
-- Merge vertically for real address
--
------------------------------------
-- s n p @ t . o
--  k i e k c c m
------------------------------------

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

[Marin David Condic]

That depends on what you mean by the "Debugger". I've got embedded code that
contains within it a "monitor" that will plug to addresses and read from
addresses. It gets requests/data from a communications mechanism and sends
replies/data down the same wire. This is relatively easy to do in an
embedded project. What I'd like to do is build something at the other end
that knows the addresses of the linked image and can send requests to plug
certain ones and get back the contents of certain other ones. I already have
something that does this with the embedded system. So if I basically took
the same code and did what I needed to it to get it to run on a PC, I'd just
need the symbol table so I could be sending the correct addresses. I don't
think I need the debugger - I just need the addresses and the ability to
build an image where nothing is going to stop me from reading/writing to
those addresses.

The whole project is considerably more complicated than this, but it is
predicated on being able to make this (or some similar) "Monitor" inside the
code work on a PC/Workstation and be able to get the symbol table for the
linked image so you know what to tell the monitor to plug & chug. I don't
want to involve a debugger if I don't have to and I don't see how having one
would help me here.

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

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:v5d1iho1q1k259@corp.supernews.com...
>
> If your target is Windows, the only way to do what you want (read and
> write another process) is to use the debugger interface. Essentially,
> you're writing a debugger. I've done that on Windows, and it isn't fun.
>
> If you were using Janus/Ada, and you asked real nice, I could give you
> the code to the debugger, and you'd have everything you need (symbol
> table access, debugger engine, etc.). I suppose you might be able to
> find similar code for GNAT with some effort (although I suspect you'd
> rather use the All-Ada source code of Janus/Ada and JDebug as opposed to
> the C (?) source of GDB).
>
>                   Randy.
>
>

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

[Marin David Condic]

All I want is the symbol table. I've got the entire rest of the thing
handled if I can get the symbol table and don't have an OS stopping me from
reading addresses. I probably can't utilize a debugger because it is too
much rework on what is already in place, changes the operating concepts
dramatically and would probably introduce too much delay into things. The
project isn't really for debugging so a debugger is simultaneously too much
and too little and I don't want to complicate the issue. What I want is the
symbol table.

I'm going to start presuming that since nobody has said "All you have to do
is type gnatmake xxx -largs<something>" to get a symbol table...." that
nothing in Gnat produces a symbol table - or that everyone is ignorant of
how to make that happen. Its a pretty simple switch for XD-Ada to make one,
so I have to believe it was never a concern for the writers of Gnat to
produce one. Perhaps some other solution exists by reading/processing other
artifacts that come out of Gnat, but it isn't obvious from here. I'll have
to poke around a bit more, but my presumption at the moment is that a
solution does not exist.

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

sk <sk@noname.com> wrote in message
news:mailman.37.1045892546.9948.comp.lang.ada@ada.eu.org...
>
> ... seriously, the map-file, spawn gdb, expect method might be the
> closest you get at controlling an "image" without altering the source
> or buying sophisticated hardware.
>

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

[Jeffrey Creem]

Sorry, I was not paying attention to this thread.

Is there any reason you can't use nm on the resulting executable to get the
symbols you want?


"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:b384nl$nag$1@slb9.atl.mindspring.net...
> All I want is the symbol table. I've got the entire rest of the thing

> artifacts that come out of Gnat, but it isn't obvious from here. I'll have
> to poke around a bit more, but my presumption at the moment is that a
> solution does not exist.
>
>

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

[Marin David Condic]

I don't know what "nm" is or what its output looks like. If it will produce
the names of variables, type information and addresses, it might work. Any
pointers on where to get it and how to use it? Does it work on Windows?

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

Jeffrey Creem <jeff@thecreems.com> wrote in message
news:8_O5a.198854$iG3.23506@sccrnsc02...
> Sorry, I was not paying attention to this thread.
>
> Is there any reason you can't use nm on the resulting executable to get
the
> symbols you want?
>
>
> "Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
> news:b384nl$nag$1@slb9.atl.mindspring.net...
> > All I want is the symbol table. I've got the entire rest of the thing
>
> > artifacts that come out of Gnat, but it isn't obvious from here. I'll
have
> > to poke around a bit more, but my presumption at the moment is that a
> > solution does not exist.
> >
> >
>
>

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

[Simon Wright]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> I don't know what "nm" is or what its output looks like. If it will
> produce the names of variables, type information and addresses, it
> might work. Any pointers on where to get it and how to use it? Does
> it work on Windows?

nm will give you the address corresponding to a (linker) symbol.
Relating that to an Ada name can be problematic. You won't get
type info.

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

[Marin David Condic]

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

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

Simon Wright <simon@pushface.org> wrote in message
news:x7vof51r0om.fsf@smaug.pushface.org...
>
> nm will give you the address corresponding to a (linker) symbol.
> Relating that to an Ada name can be problematic. You won't get
> type info.

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

[Randy Brukardt]

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.

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

[Marin David Condic]

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

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

[tmoran]

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

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

[Stephen Leake]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Too bad Gnat doesn't seem to dump its symbol tables in a readily accessible
> manner. 

Have you tried asking ACT?

-- 
-- Stephe

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

[Marin David Condic]

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.

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

[Marin David Condic]

An interesting chicken/egg problem. If I had a real & significant project
that used Gnat and had a need for the kind of support ACT can provide, I
could go to the customer and suggest we need a budget to pay ACT their
non-trivial support fees. But if I don't have a project that requires the
expertise of the compiler writers, nobody is going to pony-up the cashish to
pay them to answer my questions. The only way to possibly get a project
going of this sort is to demonstrate to the customer that you've got
something that could work if only they'll give you some bunch of money. I
can't do that unless I can get my questions answered concerning symbol
tables and accessibility of memory. So there you are. I'm asking on C.L.A.
because its a good source for free advice and user tips.

BTW, given the nature of the project, Gnat need not be the only player. I
already don't use Gnat for the embedded compilation, so I'm buying into all
sorts of compiler incompatibilities already. (That's a more serious
long-range problem, but one I think I could solve.) So other compilers are
possible to consider, but again, I can't go out and buy a bunch of them for
evaluation and do this "On Spec". I've got to come up with a proposal for
something I think is doable and sellable with little time and no money.

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

Stephen Leake <Stephen.A.Leake@nasa.gov> wrote in message
news:u1y1u6ffo.fsf@nasa.gov...
> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>
> > Too bad Gnat doesn't seem to dump its symbol tables in a readily
accessible
> > manner.
>
> Have you tried asking ACT?
>
> --
> -- Stephe

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

[Stephen Leake]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> <snip> I can't go out and buy a bunch of them for
> evaluation and do this "On Spec". 

You don't have to spend money to get evaluation support. As long as
there is a real possibility of money after a positive evaluation, any
compiler company will give you free support for evaluation (for a
limited time).

-- 
-- Stephe

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

[tmoran]

> 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
  Given
    package One is
      Global_Voltage : Integer;
      ...
    end One;
    package Two is
      Global_Red_Button_Pushed : Boolean;
      ...
   end Two;
   ...
How about adding
  package Self_Description is
  begin -- run once at package Self_Description's elaboration time
    Tell_Monitor("One.Global_Voltage", One.Global_Voltage'address);
    Tell_Monitor("Two.Global_Red_Button_Pushed",
                 Two.Global_Red_Button_Pushed'address);
    ...
  end Self_Description;
Assuming of course that 'address in the testee program is meaningful
to the monitor program.

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

[Marin David Condic]

We did this with a small part of the system once. We extracted out a
realtime model and had special packages that collected up references to the
various parameters of interest. It worked, but it wasn't pretty. Every time
the realtime model changed we were in there editing those packages to
add/delete variables and recompiling the whole mess. It was effective and
given the limited scope, not so painful that it stopped us from using it.

Here I don't think that would work. The number of variables gets so high and
can be so dynamic that it would likely be way too difficult to deal with at
that level. Just about the time you got the code rebuilt, someone would
issue a new release and you're back to ground zero.

Besides, it would not work within the context of the existing toolset and
test cases. The idea here was a minimal impact sort of thing - a kind of
extension to something they already had. You start changing the concepts too
much and the scope of the project has to get too big to sell.

An alternative I may have to look at is to see what sort of interfaces I've
got at the lowest level and, since I've got to dummy-up the A/D reads, etc
anyway, there may be some way of making that accept I/O from a different
source with less impact to the system. Of course, this totally blows away my
existing internal and external monitor software and test cases, but if I
were to go that route, there may be other benefits that make it worth coming
up with a new environment.

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:Kns7a.286366$be.259256@rwcrnsc53...
> > 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
>   Given
>     package One is
>       Global_Voltage : Integer;
>       ...
>     end One;
>     package Two is
>       Global_Red_Button_Pushed : Boolean;
>       ...
>    end Two;
>    ...
> How about adding
>   package Self_Description is
>   begin -- run once at package Self_Description's elaboration time
>     Tell_Monitor("One.Global_Voltage", One.Global_Voltage'address);
>     Tell_Monitor("Two.Global_Red_Button_Pushed",
>                  Two.Global_Red_Button_Pushed'address);
>     ...
>   end Self_Description;
> Assuming of course that 'address in the testee program is meaningful
> to the monitor program.

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

[tmoran]

> We did this with a small part of the system once. ...  Every time
> the realtime model changed we were in there editing those packages to
> add/delete variables and recompiling the whole mess.
  If you add a new control or sensor variable to the system under
test, it seems to me you necessarily have to add some information
about it to the monitoring system, no?  A package that simply 'with's
the packages with global variables should be a) automatically buildable,
and b) require nothing but recompilation of that single package
and a relink, when you change the set of variables.  What am I missing?

> The idea here was a minimal impact sort of thing
  A package whose execution happens entirely at elaboration time, and
which never does anything thereafter, seems like a fairly minimal impact,
unless of course you are trying to monitor elaboration itself.

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

[tmoran]

Write a source code scanner (ASIS?) to find variables you want to
monitor/modify.  This should produce as output a package that looks
like this:

package my_symbols is
  pragma elaborate_body;
  global : integer;  -- a line like this for each variable of interest
end my_symbols;

with ada.streams,
     ada.streams.stream_io,
     system;
package body my_symbols is
  f : ada.streams.stream_io.file_type;
  s : ada.streams.stream_io.stream_access;
begin
  ada.streams.stream_io.create(f, ada.streams.stream_io.out_file,
                               "my_symbols.dat");
  s := ada.streams.stream_io.stream(f);
  --
  String'Output(S, "Global");           -- this line pair for each variable
  System.Address'Output(S, Global'address);
  --
  ada.streams.stream_io.close(f);
end my_symbols;

Then add "with my_symbols" to your testee program.  Recompilation will compile
my_symbols.ads, my_symbols.adb, and testee.adb, which should be pretty quick.  Then
Relink and run testee just long enough for elaboration to produce the
my_symbols.dat file.

my_symbols.dat is your desired symbol table.  Massage it, read it into a
database, print it in hex, generate source code like
  Addr_Global : constant System.Address := 16#1234#;
or whatever.  Your monitor program now has the symbol table and can do
whatever you want using it.  My_symbols still exists and runs as part of
elaboration of testee, so addresses don't change, but once it's written
its output it should have no further effect on the running of testee.

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

[John R. Strohm]

This is probably one of those places where AWK would be a better choice.

Build a file with variable name and type.

Use one AWK script to read that file and write the necessary Ada package
spec to create the variables.

Use another AWK script to read that file and generate the monitoring code
for the variables.

Then your build process ("makefile") runs the AWK scripts when the variable
file changes, and then recompiles the created package spec and monitoring
code.

<tmoran@acm.org> wrote in message news:6AP7a.297368$be.266482@rwcrnsc53...
> Write a source code scanner (ASIS?) to find variables you want to
> monitor/modify.  This should produce as output a package that looks
> like this:
>
> package my_symbols is
>   pragma elaborate_body;
>   global : integer;  -- a line like this for each variable of interest
> end my_symbols;
>
> with ada.streams,
>      ada.streams.stream_io,
>      system;
> package body my_symbols is
>   f : ada.streams.stream_io.file_type;
>   s : ada.streams.stream_io.stream_access;
> begin
>   ada.streams.stream_io.create(f, ada.streams.stream_io.out_file,
>                                "my_symbols.dat");
>   s := ada.streams.stream_io.stream(f);
>   --
>   String'Output(S, "Global");           -- this line pair for each
variable
>   System.Address'Output(S, Global'address);
>   --
>   ada.streams.stream_io.close(f);
> end my_symbols;
>
> Then add "with my_symbols" to your testee program.  Recompilation will
compile
> my_symbols.ads, my_symbols.adb, and testee.adb, which should be pretty
quick.  Then
> Relink and run testee just long enough for elaboration to produce the
> my_symbols.dat file.
>
> my_symbols.dat is your desired symbol table.  Massage it, read it into a
> database, print it in hex, generate source code like
>   Addr_Global : constant System.Address := 16#1234#;
> or whatever.  Your monitor program now has the symbol table and can do
> whatever you want using it.  My_symbols still exists and runs as part of
> elaboration of testee, so addresses don't change, but once it's written
> its output it should have no further effect on the running of testee.