This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: debuginformation generated by GNAT


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]