Re: debuginformation generated by GNAT

[Roul Oldenburger <oldenburger.roul@rheinmetall-de.com>]

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