From: Roul Oldenburger <oldenburger.roul@rheinmetall-de.com>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb@sources.redhat.com
Subject: Re: debuginformation generated by GNAT
Date: Fri, 21 Nov 2003 14:58:00 -0000 [thread overview]
Message-ID: <3FBE277F.5020005@rheinmetall-de.com> (raw)
In-Reply-To: <20031120182051.GB1186@gnat.com>
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.
>
next prev parent reply other threads:[~2003-11-21 14:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-18 16:01 Roul Oldenburger
2003-11-18 18:51 ` Joel Brobecker
2003-11-20 15:49 ` Roul Oldenburger
2003-11-20 18:20 ` Joel Brobecker
2003-11-21 14:58 ` Roul Oldenburger [this message]
2003-11-21 19:46 ` Joel Brobecker
2003-11-24 14:19 ` Roul Oldenburger
2003-12-09 20:37 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FBE277F.5020005@rheinmetall-de.com \
--to=oldenburger.roul@rheinmetall-de.com \
--cc=brobecker@gnat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox