debuginformation generated by GNAT

debuginformation generated by GNAT

[Roul Oldenburger]

Hello everybody,

I was looking for explanation for certain debug symbols gnat generated 
from our ada sources. Joel pointed me to exp_debug.ads where most of my 
questions were answered, but now I am in trouble again.

Trying to reconstruct structure type trees from debuginformation given 
by binutils objdump and parsed by a program of mine ... I got stuck 
where I have to compute the size of an ___XVL component (entity with 
variable length) which is an array.

(objdump output)
.
.
struct gen_siso_common_types__bdt_spectral_description___XVE { /* size 4 
id 1546 */
   gen_siso_common_types__bdt_spectral_description__T73s *cas___XVL; /* 
bitsize 32, bitpos 0 */
   gen_siso_common_types__bdt_spectral_description__T75s *fas___XVL4; /* 
bitsize 32, bitpos 0 */
   gen_siso_common_types__bdt_spectral_description__T77s *tas___XVL4; /* 
bitsize 32, bitpos 0 */
};
.
.

(corresponding ada code)
.
.
    type Spectral_Table is
       array (Index range <>) of Basic.Float32; -- Intensitaetsfaktoren

    type Bdt_Spectral_Description is
       record
          Cas : Spectral_Table(1 .. Bdt_Cas_Bands); -- BDT-Spektrum CAS
          Fas : Spectral_Table(1 .. Bdt_Fas_Bands); -- BDT-Spektrum FAS
          Tas : Spectral_Table(1 .. Bdt_Tas_Bands); -- BDT-Spektrum TAS
       end record;
.
.

When I understood exp_debug.ads right I cannot compute the size of such 
array ... but the debugger surely knows it.

Can someone help?


Thanks very much
Roul

Re: debuginformation generated by GNAT

[Joel Brobecker]

> struct gen_siso_common_types__bdt_spectral_description___XVE { /* size 4 
> id 1546 */
>   gen_siso_common_types__bdt_spectral_description__T73s *cas___XVL; /* 
> bitsize 32, bitpos 0 */
>   gen_siso_common_types__bdt_spectral_description__T75s *fas___XVL4; /* 
> bitsize 32, bitpos 0 */
>   gen_siso_common_types__bdt_spectral_description__T77s *tas___XVL4; /* 
> bitsize 32, bitpos 0 */
> };

This is one of the difficult parts of decoding Ada structures.
The relevant part of exp_dbug.ads is the following:

      --  The idea is to encode not the position, but rather information
      --  that allows computing the position of a field from the position
      --  of the previous field. The algorithm for computing the actual
      --  positions of all fields and the length of the record is as
      --  follows. In this description, let P represent the current
      --  bit position in the record.

      --    1. Initialize P to 0.

      --    2. For each field in the record,

      --       2a. If an alignment is given (see below), then round P
      --       up, if needed, to the next multiple of that alignment.

      --       2b. If a bit position is given, then increment P by that
      --       amount (that is, treat it as an offset from the end of the
      --       preceding record).

      --       2c. Assign P as the actual position of the field.

      --       2d. Compute the length, L, of the represented field (see below)
      --       and compute P'=P+L. Unless the field represents a variant part
      --       (see below and also Variant Record Encoding), set P to P'.

IIRC, the ___XVL fields are just access fields, and their size is
provided by the debug info (bitsize = 32).

If you have any trouble understanding how to decode some debugging
information, I suggest you check our debugger code to see how it
performs its task. We provide a read-only CVS access to our sources
on libre.act-europe.fr.

> When I understood exp_debug.ads right I cannot compute the size of
> such array ... but the debugger surely knows it.

Computing the size of an array should be easy, although you can
have either fat pointers or thin pointers. But it should be well
explained in exp_dbug.ads.

-- 
Joel

Re: debuginformation generated by GNAT

[Roul Oldenburger]

Hi Joel,

sorry for bothering you again with this but I fear it will take me ages 
to get the answers from gdb sources because I probably will get lost in 
it and I guess, I hope my question is a simple one for you.

Having read exp_dbug.ads, hoping I understood how to compute P ... you 
have pointed me to the algorithm below again ... where it says 'compute 
the length, L, of the represented field (see below)' and below I find 
several paragraphs for the different data types.

Following the actual example I got:

-----
struct gen_siso_common_types__bdt_spectral_description___XVE { /* size 4 
id 1546 */
   gen_siso_common_types__bdt_spectral_description__T73s *cas___XVL; /* 
bitsize 32, bitpos 0 */
   gen_siso_common_types__bdt_spectral_description__T75s *fas___XVL4; /* 
bitsize 32, bitpos 0 */
   gen_siso_common_types__bdt_spectral_description__T77s *tas___XVL4; /* 
bitsize 32, bitpos 0 */
};
-----
I then look at
-----
struct gen_siso_common_types__bdt_spectral_description__T77s___XA { /* 
size 4 id 1545 */
   long int 
gen_siso_common_types__bdt_spectral_description__T76s___XDL_1; /* 
bitsize 32, bitpos 0 */
};
-----
and
-----
typedef range (awu_siso_basic_types__Tnatural32B):1:-1 
gen_siso_common_types__bdt_spectral_description__T76s___XDL_1;
-----
also I found
-----
typedef awu_siso_basic_types__float32 
gen_siso_common_types__bdt_spectral_description__T77s[1:-1]:int32;
-----
and last
-----
gen_siso_common_types__index___XDLU_0__2147483647 
gen_siso_common_types__bdt_spectral_description__T76s___U /* 0x88d0b6c */;
----------

The first tells me 'tas' has a variable length and needs an alignment of 
4 storage units ... the given field is as you said the access field.
As I understood it is just a substitute or does it actually represent 
the pointer to the array behind it.

The second tells me it actually is an array .... exp_debug.ads:
       -----------------
       -- Array Types --
       -----------------

       --  Since there is no way for the debugger to obtain the index 
subtypes
       --  for an array type, we produce a type that has the name of the
       --  array type followed by "___XA" and is a record whose field names
       --  are the names of the types for the bounds. The types of these
       --  fields is an integer type which is meaningless.

       --  To conserve space, we do not produce this type unless one of
       --  the index types is either an enumeration type, has a variable
       --  upper bound, has a lower bound different from the constant 1,
       --  is a biased type, or is wider than "sizetype".

       --  Given the full encoding of these types (see above description for
       --  the encoding of discrete types), this means that all necessary
       --  information for addressing arrays is available. In some
       --  debugging formats, some or all of the bounds information may
       --  be available redundantly, particularly in the fixed-point case,
       --  but this information can in any case be ignored by the debugger.

So I understand 
"gen_siso_common_types__bdt_spectral_description__T76s___XDL_1"
is the type which represents the bounds of the array and it is already 
said the lower bound is 1 and the upper is dynamic.
The paragraph about discrete types then tells me about the object that 
has the same name followed by an ___U which holds the upper bound of the 
array. It is
gen_siso_common_types__index___XDLU_0__2147483647 
gen_siso_common_types__bdt_spectral_description__T76s___U /* 0x88d0b6c */;

Now two questions ... please hold on and don't get angry...

what does it mean? ... the upper bound is a value between 0 and 
2147483647 and is stored at address 0x88d0b6c and the address is the 
offset within the file?

Is there any easier way to determine the size of such an array? ... I've 
seen something like this
long int gen_siso_common_types__bdt_spectral_description__T77s___SIZE /* 
0x88d0b70 */;

it is not mentioned in exp_debug.ads ... probably too obvious ... but I 
would think the size of the array is stored at the given address in the 
file???

The problem is I've restricted myself to only use output generated by 
objdump although I first thought of using libbfd. Is there another place 
I could find the size of an array ... symbol table ... using a different 
tool??

Many thanks for reading my endless explanations and questions and for 
your help

Roul

Joel Brobecker wrote:
>>struct gen_siso_common_types__bdt_spectral_description___XVE { /* size 4 
>>id 1546 */
>>  gen_siso_common_types__bdt_spectral_description__T73s *cas___XVL; /* 
>>bitsize 32, bitpos 0 */
>>  gen_siso_common_types__bdt_spectral_description__T75s *fas___XVL4; /* 
>>bitsize 32, bitpos 0 */
>>  gen_siso_common_types__bdt_spectral_description__T77s *tas___XVL4; /* 
>>bitsize 32, bitpos 0 */
>>};
> 
> 
> This is one of the difficult parts of decoding Ada structures.
> The relevant part of exp_dbug.ads is the following:
> 
>       --  The idea is to encode not the position, but rather information
>       --  that allows computing the position of a field from the position
>       --  of the previous field. The algorithm for computing the actual
>       --  positions of all fields and the length of the record is as
>       --  follows. In this description, let P represent the current
>       --  bit position in the record.
> 
>       --    1. Initialize P to 0.
> 
>       --    2. For each field in the record,
> 
>       --       2a. If an alignment is given (see below), then round P
>       --       up, if needed, to the next multiple of that alignment.
> 
>       --       2b. If a bit position is given, then increment P by that
>       --       amount (that is, treat it as an offset from the end of the
>       --       preceding record).
> 
>       --       2c. Assign P as the actual position of the field.
> 
>       --       2d. Compute the length, L, of the represented field (see below)
>       --       and compute P'=P+L. Unless the field represents a variant part
>       --       (see below and also Variant Record Encoding), set P to P'.
> 
> IIRC, the ___XVL fields are just access fields, and their size is
> provided by the debug info (bitsize = 32).
> 
> If you have any trouble understanding how to decode some debugging
> information, I suggest you check our debugger code to see how it
> performs its task. We provide a read-only CVS access to our sources
> on libre.act-europe.fr.
> 
> 
>>When I understood exp_debug.ads right I cannot compute the size of
>>such array ... but the debugger surely knows it.
> 
> 
> Computing the size of an array should be easy, although you can
> have either fat pointers or thin pointers. But it should be well
> explained in exp_dbug.ads.
> 

Re: debuginformation generated by GNAT

[Joel Brobecker]

> The first tells me 'tas' has a variable length and needs an alignment of 
> 4 storage units ... the given field is as you said the access field.

Right.

> As I understood it is just a substitute or does it actually represent 
> the pointer to the array behind it.

In memory, this is a pointer to your array. From the user's perspective,
though, the ___XVL suffix tells you that he believes it's just an array.

> The second tells me it actually is an array .... exp_debug.ads:

Did GNAT generate any ___XUP or ___XUT type, that's where the bounds are
stored when the upper bounds are dynamic. See "Pointers to Unconstrained
Arrays".

The types you were looking at are useful when you are trying to print
the type of the array type itself, not the type of the field, I believe.

-- 
Joel

Re: debuginformation generated by GNAT

[Roul Oldenburger]

Yes GNAT did ...

-- XUP
struct gen_siso_common_types__spectral_table___XUP { /* size 8 id 1475 */
   gen_siso_common_types__spectral_table___XUA *P_ARRAY; /* bitsize 32, 
bitpos 0 */
   struct gen_siso_common_types__spectral_table___XUB /* id 1474 */ 
*P_BOUNDS; /* bitsize 32, bitpos 32 */
};

-- XUT
struct gen_siso_common_types__spectral_table___XUT___XVE { /* size 4 id 
1476 */
   struct gen_siso_common_types__spectral_table___XUB /* id 1474 */ 
BOUNDS; /* bitsize 64, bitpos 0 */
   gen_siso_common_types__spectral_table___XUA *ARRAY___XVL; /* bitsize 
32, bitpos 0 */
};

-- leads to XUB
struct gen_siso_common_types__spectral_table___XUB { /* size 8 id 1474 */
   awu_siso_basic_types__Tnatural32B LB0; /* bitsize 32, bitpos 0 */
   awu_siso_basic_types__Tnatural32B UB0; /* bitsize 32, bitpos 32 */
};



But not for 'bdt_spectral_description'


struct gen_siso_common_types__bdt_spectral_description___XVE { /* size 4 
id 1546 */
   gen_siso_common_types__bdt_spectral_description__T73s *cas___XVL; /* 
bitsize 32, bitpos 0 */
   gen_siso_common_types__bdt_spectral_description__T75s *fas___XVL4; /* 
bitsize 32, bitpos 0 */
   gen_siso_common_types__bdt_spectral_description__T77s *tas___XVL4; /* 
bitsize 32, bitpos 0 */
};

struct gen_siso_common_types__bdt_spectral_description__T77s___XA { /* 
size 4 id 1545 */
   long int 
gen_siso_common_types__bdt_spectral_description__T76s___XDL_1; /* 
bitsize 32, bitpos 0 */
};


Thanks again

Roul


Joel Brobecker wrote:
>>The first tells me 'tas' has a variable length and needs an alignment of 
>>4 storage units ... the given field is as you said the access field.
> 
> 
> Right.
> 
> 
>>As I understood it is just a substitute or does it actually represent 
>>the pointer to the array behind it.
> 
> 
> In memory, this is a pointer to your array. From the user's perspective,
> though, the ___XVL suffix tells you that he believes it's just an array.
> 
> 
>>The second tells me it actually is an array .... exp_debug.ads:
> 
> 
> Did GNAT generate any ___XUP or ___XUT type, that's where the bounds are
> stored when the upper bounds are dynamic. See "Pointers to Unconstrained
> Arrays".
> 
> The types you were looking at are useful when you are trying to print
> the type of the array type itself, not the type of the field, I believe.
> 

Re: debuginformation generated by GNAT

[Joel Brobecker]

> struct gen_siso_common_types__bdt_spectral_description__T77s___XA { /* 
> size 4 id 1545 */
>   long int 
> gen_siso_common_types__bdt_spectral_description__T76s___XDL_1; /* 
> bitsize 32, bitpos 0 */
> };

this part is telling you that the lower bound is static and equal to 1.
The upper bound is dynamic and needs to be read in memory: GNAT should
generate a ___U *variable*, something like this:

    gen_siso_common_types__bdt_spectral_description__T76s___U

BTW: Is this a personal project of yours? Could you tell us more about
what you are trying to do, and what you are using Ada for?
-- 
Joel

Re: debuginformation generated by GNAT

[Roul Oldenburger]

Thankyou Joel,

indeed there is the following

gen_siso_common_types__index___XDLU_0__2147483647 
gen_siso_common_types__bdt_spectral_description__T76s___U /* 0x88d0b6c */;

Does this variable found at the given address/offset(?) holds the upper 
bound?
So if I say in case of such an array the actual size won't be given 
within the debugging output but only by reading for example this 
variable in order to calculate it? (sorry for the terribly long sentence)

This project is not a personal one. It is part of a bigger one in the 
company I am working for.
A bit background:
The project uses several shared memories for ipc. We use a tool of our 
own to monitor the shared memories. The configuration files the tool 
needs were generated so far by seperate programs which use the shared 
memory specs. Because the shared memories themselves are in development 
the specs are changing more or less often. Due to this the programs 
which generate the config files have to be maintained with each change 
on the shared memory structures.

The aim now is to find a way to generate reliable configuration 
information automatically. And the idea was to use the debuginformation 
the compiler adds to the executable.

I've written a perl program that parses objdump's output and is able to 
reconstruct trees of structure type descriptions and writes the 
configuration file for our monitor tool.

This was fine until I came across structure type descriptions which 
contain components of variable length.

For the usual not-XVE case objdump delivers type designators, component 
names, offsets and sizes in (mostly) direct readable form. This was 
wasn't an impossible task to do using perl but with variable length 
entities it seems like more must be done.

Ada simply is the language the specs are written in due to customer 
requirements.


I am looking forward to your suggestions and opinions.

Thanks
Roul


Joel Brobecker wrote:
>>struct gen_siso_common_types__bdt_spectral_description__T77s___XA { /* 
>>size 4 id 1545 */
>>  long int 
>>gen_siso_common_types__bdt_spectral_description__T76s___XDL_1; /* 
>>bitsize 32, bitpos 0 */
>>};
> 
> 
> this part is telling you that the lower bound is static and equal to 1.
> The upper bound is dynamic and needs to be read in memory: GNAT should
> generate a ___U *variable*, something like this:
> 
>     gen_siso_common_types__bdt_spectral_description__T76s___U
> 
> BTW: Is this a personal project of yours? Could you tell us more about
> what you are trying to do, and what you are using Ada for?

Re: debuginformation generated by GNAT

[Joel Brobecker]

> gen_siso_common_types__index___XDLU_0__2147483647 
> gen_siso_common_types__bdt_spectral_description__T76s___U /* 0x88d0b6c */;
> 
> Does this variable found at the given address/offset(?) holds the upper 
> bound?

Yes.

> So if I say in case of such an array the actual size won't be given 
> within the debugging output but only by reading for example this 
> variable in order to calculate it?

Yes.

In terms of the user's perspective, the size of the array is not static,
it can not be determined at compilation time. So depending on what you
need to do, you can either print that the upper bound is unknown (in
GDB, we print ranges like this "(1 .. ?)", or you can also read the
value from memory, but then you'll need to start your program.

-- 
Joel