Ada Type Information

Ada Type Information

[Sam Carnicelli]

I've been lurking around this newsgroup for a couple of weeks and
I thought some
of the people here might be able to offer some valuable advice.

We have a need to convert Ada95 type information into a neutral format
for use by
a tool written in Java.  We basically need, given a record type, the
type starting bit
position, and length in bits of all fields of a record.  For instance,
given this record
definition:

type ENUM_T is (
   FIRST,
   SECOND,
   THIRD);

type EXAMPLE_T is record
   Field1 : STRING(1..10);
   Field2 : INTEGER;
   Field3 : FLOAT;
   Field4 : ENUM_T
 end record;

We would need the following data (all sizes are in bits and are my
approximations):

Type_Name:   EXAMPLE_T
Type_Size:      176

Field_Name: Field1
Field_Type : STRING
Size: 80
Start_Bit: 0

Field_Name: Field2
Field_Type: INTEGER
Size: 32
Start_Bit: 80

Field_Name: Field3
Field_Type: FLOAT
Size: 32
Start_Bit: 112

Field_Name: Field4
Field_Type: ENUM
Size: 32
Start_Bit: 144
Num_Enum_Codes: 3
Enum_Codes:  FIRST, SECOND, THIRD

This would have to get past the various layers of derived types,
renames, etc to
get to the underlying base types such as those above.

Creating this data manually is very tedious, particularly when you have
large,
nested record structures.

We are using GNAT 3.11b on Solaris.  We have looked at a few options for

getting this
data, such as.....

1) Compiling with -g and -S to get assembly code.  The assembly code
contains "stabs"
debug data which probably contains the needed information.  However, we
could not find a good
set of documentation on the stabs format for Suns.  Documentation that
we did find mentioned
that Suns did things a little differently than the standard.   The
thought was to build a table of
type data and decompose the desired record based on the types it
contained, etc.

2) Using the wavefront version of GNAT 3.12w.  This has a -gnatR flag
which produces rep spec
information at compilation.  This is good for sizing and layout of
records, but didn't seem to have
the necessary type information.

3) Using ASIS for GNAT.  We've spent some time with this.  We can get
down to specific types
of record components.  If the types used are sized with representations
clauses, we can get the
size information.  If records are rep spec'd, we can get the required
layout information.
What we haven't figured out is whether we can get record layout
information in the absence of a
rep spec.   Is this possible with ASIS for GNAT?  Has anyone done/seen
anything using ASIS
remotely similar to what we're trying to do?

Any help/advice would be greatly appreciated.
Thanks



--
------------------------------------------------------------------
Sam Carnicelli
Lockheed Martin                         Phone : 315-456-2881
Syracuse, NY 13221-4840                 Fax   : 315-456-0107

e-mail: samuel.charles.carnicelli@lmco.com
------------------------------------------------------------------

Re: Ada Type Information

[Tom Moran]

>given a record type, the
>type starting bit
>position, and length in bits of all fields of a record
If there's no rep spec, then there's no guaranteed layout.  Different
compilers may do it differently, or according to the phases of the
moon.  
  At run time, if you have an appropriate piece of code, it could
determine things using the storage place attributes, eg
R.Field1'Position, R.Field1.First_Bit, etc.  Could you make a tool
using ASIS to tell the types, and generate code to tell the positions?

Re: Ada Type Information

[Sam Carnicelli]

Tom Moran wrote:

> >given a record type, the
> >type starting bit
> >position, and length in bits of all fields of a record
> If there's no rep spec, then there's no guaranteed layout.  Different
> compilers may do it differently, or according to the phases of the
> moon.

With any of the methods I mentioned in my original post, the information
should still be available.The stabs data comes from the compiler, so it
would have the layout information.
The rep spec data produced by the -gnatR flag obviously has the
information.
ASIS uses data from the tree file produced by the compiler.  Again, the
data should be available.

>   At run time, if you have an appropriate piece of code, it could
> determine things using the storage place attributes, eg
> R.Field1'Position, R.Field1.First_Bit, etc.  Could you make a tool
> using ASIS to tell the types, and generate code to tell the positions?

I suppose I could generate some code, but it seems like there must be an
easier way???



--
------------------------------------------------------------------
Sam Carnicelli
Lockheed Martin                         Phone : 315-456-2881
Syracuse, NY 13221-4840                 Fax   : 315-456-0107

e-mail: samuel.charles.carnicelli@lmco.com
------------------------------------------------------------------

Re: Ada Type Information

[dewar]

In article <36E03843.3AD74457@lmco.com>,
  Sam Carnicelli <samuel.charles.carnicelli@lmco.com>
wrote:

> I've been lurking around this newsgroup for a couple of
> weeks and I thought some of the people here might be able
> to offer some valuable advice.

Since you mention the -gnatR switch in the latest 3.12
GNAT technology, let me say exactly what this does. For
all named array and record types in the program it gives
the type name, and the representation characteristics.

I must say I am a bit puzzled as to why this does not
give you all the information you want. Here is some sample
output from -gnatR:

Source
------

procedure q is
   type r is record
      a : integer := 0;
      s : string (1 .. 5);
      t : integer;
   end record;
begin
   null;
end q;

Output from -gnatR
------------------

Representation information for unit q
--------------------------------------

for r'Object_Size use 128;
for r use record
   a at  0 range  0 .. 31;
   s at  4 range  0 .. 39;
   t at 12 range  0 .. 31;
end record;

Robert Dewar
Ada Core Technologies



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada Type Information

[Tom Moran]

>I must say I am a bit puzzled as to why this does not
>give you all the information you want.
I think he wants both type and layout for a field together, rather
than separately.
> This has a -gnatR flag
>which produces rep spec
>information at compilation.  This is good for sizing and layout of
>records, but didn't seem to have
>the necessary type information.

Re: Ada Type Information

[Sam Carnicelli]

Tom Moran wrote:
> 
> >I must say I am a bit puzzled as to why this does not
> >give you all the information you want.
> I think he wants both type and layout for a field together, rather
> than separately.

Exactly!!!


> > This has a -gnatR flag
> >which produces rep spec
> >information at compilation.  This is good for sizing and layout of
> >records, but didn't seem to have
> >the necessary type information.

-- 
------------------------------------------------------------------
Sam Carnicelli
Lockheed Martin				Phone : 315-456-2881
Syracuse, NY 13221-4840			Fax   : 315-456-0107

e-mail: samuel.charles.carnicelli@lmco.com
------------------------------------------------------------------

Re: Ada Type Information

[Sam Carnicelli]

dewar@gnat.com wrote:
> 
> In article <36E03843.3AD74457@lmco.com>,
>   Sam Carnicelli <samuel.charles.carnicelli@lmco.com>
> wrote:
> 
> > I've been lurking around this newsgroup for a couple of
> > weeks and I thought some of the people here might be able
> > to offer some valuable advice.
> 
> Since you mention the -gnatR switch in the latest 3.12
> GNAT technology, let me say exactly what this does. For
> all named array and record types in the program it gives
> the type name, and the representation characteristics.
> 
> I must say I am a bit puzzled as to why this does not
> give you all the information you want. Here is some sample
> output from -gnatR:
> 
> Source
> ------
> 
> procedure q is
>    type r is record
>       a : integer := 0;
>       s : string (1 .. 5);
>       t : integer;
>    end record;
> begin
>    null;
> end q;
> 
> Output from -gnatR
> ------------------
> 
> Representation information for unit q
> --------------------------------------
> 
> for r'Object_Size use 128;
> for r use record
>    a at  0 range  0 .. 31;
>    s at  4 range  0 .. 39;
>    t at 12 range  0 .. 31;
> end record;
> 

This tells me the layout of the record, but not the types of the
components.  Assume I was trying to write a graphical debugger and
wanted to display an object of this type to the user.  Would this data
be sufficient?  I would also need type information.  If one of the
components of record type r was itelf a record, I would need to
decompose it further, and so on...


-- 
------------------------------------------------------------------
Sam Carnicelli
Lockheed Martin				Phone : 315-456-2881
Syracuse, NY 13221-4840			Fax   : 315-456-0107

e-mail: samuel.charles.carnicelli@lmco.com
------------------------------------------------------------------

Re: Ada Type Information

[robert_dewar]

In article <36E3DAB9.7D492027@lmco.com>,
  Sam Carnicelli <samuel.charles.carnicelli@lmco.com>
wrote:
> This tells me the layout of the record, but not the types
> of the components.  Assume I was trying to write a
> graphical debugger and wanted to display an object of
> this type to the user.  Would this data be sufficient?  I
> would also need type information.  If one of the
> components of record type r was itelf a record, I would
> need to decompose it further, and so on...

Semantic information of this kind is of course available
via the ASIS interface (that is the purpose of this
interface). Put together with the -gnatR information,
it will give you what you want

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada Type Information

[korisko]

In article <7bpohc$j2t$1@nnrp1.dejanews.com>, dewar@gnat.com says...
>
 
>Source
>------
>
>procedure q is
>   type r is record
>      a : integer := 0;
>      s : string (1 .. 5);
>      t : integer;
>   end record;
 
>Representation information for unit q
>--------------------------------------
>
>for r'Object_Size use 128;
>for r use record
>   a at  0 range  0 .. 31;
>   s at  4 range  0 .. 39;   <====== ??
>   t at 12 range  0 .. 31;
>end record;
 

hi,

is it hard to change -gnatR to make it also print the type of the field as 
well, maybe as a comment? 

something like
 
for r'Object_Size use 128;  
for r use record
    a at  0 range  0 .. 31;  -- Integer
    s at  4 range  0 .. 39;  -- String(1..5)
    t at 12 range  0 .. 31;  -- Integer
end record;

korisko

Re: Ada Type Information

[dennison]

In article <36E03843.3AD74457@lmco.com>,
  Sam Carnicelli <samuel.charles.carnicelli@lmco.com> wrote:

> a tool written in Java.  We basically need, given a record type, the
> type starting bit
> position, and length in bits of all fields of a record.  For instance,
> given this record
> definition:

If the record doesn't have a rep spec and size clause, this information is
not defined by the language. Depending on what use you want to make of the
information, that could be a major problem. A new version of the compiler
would be well within its rights to add or remove padding, and to completely
shuffle the order of the fields.

If its important to you that fields be in a certian place with a certian size,
you should use rep specs.


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada Type Information

[Sam Carnicelli]

dennison@telepath.com wrote:
> 
> In article <36E03843.3AD74457@lmco.com>,
>   Sam Carnicelli <samuel.charles.carnicelli@lmco.com> wrote:
> 
> > a tool written in Java.  We basically need, given a record type, the
> > type starting bit
> > position, and length in bits of all fields of a record.  For instance,
> > given this record
> > definition:
> 
> If the record doesn't have a rep spec and size clause, this information is
> not defined by the language. Depending on what use you want to make of the
> information, that could be a major problem. A new version of the compiler
> would be well within its rights to add or remove padding, and to completely
> shuffle the order of the fields.

This is why I want to get the information from a product of the
compiler.  If a new
compiler were to change the layout of the record type, I would simply
have to rerun my tool to get the new information.  All of the methods I
have mentioned make use of products of the compiler.
 
> 
> If its important to you that fields be in a certian place with a certian size,
> you should use rep specs.
> 

It would be possible to force all types to be rep spec'd in order to use
them as input to the tool, but it should not be necessary.


------------------------------------------------------------------
Sam Carnicelli
Lockheed Martin				Phone : 315-456-2881
Syracuse, NY 13221-4840			Fax   : 315-456-0107

e-mail: samuel.charles.carnicelli@lmco.com
------------------------------------------------------------------

Re: Ada Type Information

[dennison]

In article <36E3D3A6.6BAFA0DC@lmco.com>,
  Sam Carnicelli <samuel.charles.carnicelli@lmco.com> wrote:
> dennison@telepath.com wrote:
> >
> > information, that could be a major problem. A new version of the compiler
> > would be well within its rights to add or remove padding, and to completely
> > shuffle the order of the fields.
>
> This is why I want to get the information from a product of the
> compiler.  If a new
> compiler were to change the layout of the record type, I would simply
> have to rerun my tool to get the new information.  All of the methods I
> have mentioned make use of products of the compiler.

Typically the only part of a compilation environemnt that keeps this kind of
information it the debugging support.

We had a situation here where we basicly needed a mini-debugging capability
in our simulator's Instructor Operator Station. So the engineers here
reverse-engineered the debug information created by the compiler. That
solution seemed quite dangerous to me, as a compiler vendor has every reason
to believe they can change the format of that data at will (as long as they
change their debuggers to match). But such a change would require us to redo
the entire reverse-engineering process (or more likely, refuse to ever
upgrade our compiler). In the end, they were convinced to not do this (at
least on this program).

But if you stick to GCC technology, there's probably some standard for the
"-g" output. Perhaps there's even a document somewhere describing it for
prospective debugger writers. This might be a reasonable option, assuming you
are willing to keep up with any changes the gcc folks put in.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada Type Information

[Sam Carnicelli]

dennison@telepath.com wrote:
> 
> >
> > This is why I want to get the information from a product of the
> > compiler.  If a new
> > compiler were to change the layout of the record type, I would simply
> > have to rerun my tool to get the new information.  All of the methods I
> > have mentioned make use of products of the compiler.
> 
> Typically the only part of a compilation environemnt that keeps this kind of
> information it the debugging support.
> 
> We had a situation here where we basicly needed a mini-debugging capability
> in our simulator's Instructor Operator Station. So the engineers here
> reverse-engineered the debug information created by the compiler. That
> solution seemed quite dangerous to me, as a compiler vendor has every reason
> to believe they can change the format of that data at will (as long as they
> change their debuggers to match). But such a change would require us to redo
> the entire reverse-engineering process (or more likely, refuse to ever
> upgrade our compiler). In the end, they were convinced to not do this (at
> least on this program).
> 
> But if you stick to GCC technology, there's probably some standard for the
> "-g" output. Perhaps there's even a document somewhere describing it for
> prospective debugger writers. This might be a reasonable option, assuming you
> are willing to keep up with any changes the gcc folks put in.
> 
> T.E.D.

What you are describing is similar to the stabs data produced by the gcc
compiler with the -g and -S options.  It is described as a debug format
and seems to be somewhat of a standard.  It appears to have everything I
would need, but the syntax is not intuitive.  Apparently, the version
used under Solaris has some extensions and I can't find adequate
documentation.  This data is actually used by the gdb debugger....

------------------------------------------------------------------
Sam Carnicelli
Lockheed Martin				Phone : 315-456-2881
Syracuse, NY 13221-4840			Fax   : 315-456-0107

e-mail: samuel.charles.carnicelli@lmco.com
------------------------------------------------------------------

Re: Ada Type Information

[robert_dewar]

In article <7c0rvn$7os$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
>
> But if you stick to GCC technology, there's probably some
> standard for the "-g" output. Perhaps there's even a
> document somewhere describing it for prospective debugger
> writers. This might be a reasonable option, assuming you
> are willing to keep up with any changes the gcc folks put
> in

The basic standard for the -g output is of course NOT
gcc specific, since generally the system standard format
is used (e.g. MDEBUG on o32 IRIX, DWARF2 on n32 IRIX,
STABS on Solaris etc). The encodings for Ada data
structures are GNAT specific, and can be found documented
in exp_dbug.ads.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own