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: Mon, 24 Nov 2003 14:19:00 -0000 [thread overview]
Message-ID: <3FC2138B.5050900@rheinmetall-de.com> (raw)
In-Reply-To: <20031121194641.GC2498@gnat.com>
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?
next prev parent reply other threads:[~2003-11-24 14:19 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
2003-11-21 19:46 ` Joel Brobecker
2003-11-24 14:19 ` Roul Oldenburger [this message]
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=3FC2138B.5050900@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