Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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?


  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