Re: debuginformation generated by GNAT

[Joel Brobecker <brobecker@gnat.com>]

> 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