From: Joel Brobecker <brobecker@adacore.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/DWARF] Add DW_AT_GNAT_descriptive_type support
Date: Fri, 25 Dec 2009 04:36:00 -0000 [thread overview]
Message-ID: <20091225040646.GY2788@adacore.com> (raw)
In-Reply-To: <20091224193948.GA7936@host0.dyn.jankratochvil.net>
> While it may make sense from the practical point of view I would like
> a clear statement this is the reason for this "gross"
> DW_AT_GNAT_descriptive_type code.
I agree it is a bit gross. The problem is not technical difficulty;
it's resources. I said, back in Apr (wow, so long ago already!):
| At the time, we had hoped that this would be a temporary, local
| change, until we find the time to work on generating pure DWARF.
| But the reality is that we don't see this happening in the near
| future. As we've come to accept this fact, we at AdaCore think
| that it would be useful to others to be able to take advantage
| of this attribute.
|
| The changes in GDB are relatively small, I think - at least in
| the DWARF reader part.
> With properly implemented DWARF-only DW_FORM_block* producer for GNAT
> the GDB consumer would be IMO some small extension of dynamic types
> (to accept DW_FORM_block* for several more DW_AT_* attributes and
> reuse the existing dynamic->static converting code in check_typedef).
The problem is that there are lots more situations where we would
still need to fix GDB as well - as you have probably seen in the
exp_dbug.ads spec. The record with a variable-length field is just
one example. Another example would be a discriminated record, where
certain components determine the contents of the rest of the record.
Or arrays, where you need to access a parallel ___XA type. Etc.
This is definitely something that AdaCore has been looking at -
implementing the generation of proper dwarf. We looked at all
the situations where an encoding was used, and how to replace it
in DWARF. Apart from a few unknowns that have not be resolved yet,
we more or less know how to express the rest. But this effort seems
to be always stalled in favor of other, more urgent ones. It's an
effort that is actually dear to me, since I very much dislike this
encoding. But I don't want to start on this until I am done
synchronizing the Ada mode at AdaCore and the Ada mode at the FSF.
--
Joel
next prev parent reply other threads:[~2009-12-25 4:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-24 18:07 Joel Brobecker
2009-12-24 19:40 ` Jan Kratochvil
2009-12-25 4:36 ` Joel Brobecker [this message]
2009-12-25 9:40 ` Jan Kratochvil
2010-11-03 19:25 ` Jan Kratochvil
2010-11-03 20:48 ` Joel Brobecker
2010-01-05 20:12 ` Tom Tromey
2010-01-11 10:41 ` Joel Brobecker
2010-01-11 18:15 ` Tom Tromey
2010-01-12 5:53 ` 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=20091225040646.GY2788@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@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