From: Mark Wielaard <mjw@redhat.com>
To: Eric Christopher <echristo@gmail.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] DWARFv5. Handle DW_TAG_atomic_type _Atomic type modifier.
Date: Mon, 23 Jun 2014 21:34:00 -0000 [thread overview]
Message-ID: <1403559239.3970.69.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: <CALehDX4kij8kK1zaYGrMQJPLQSs8KdntAmeyWkyQvcsVJytd2w@mail.gmail.com>
On Mon, 2014-06-23 at 11:01 -0700, Eric Christopher wrote:
> FWIW a new vendor tag, even for such as this, would be a better
> solution. The numbers you choose for any attributes, if the proposals
> are accepted, would not necessarily be the same ones you chose. That
> confusion between numbers in consumers is worse than an unknown tag
> IMO.
Most certainly agreed. I normally work on other DWARF consumers and I
know all too well that whatever GCC/GDB adopts is what the rest of the
toolchain ends up having to support. The goal of the prototype patches
wasn't to get them integrated/adopted before DWARFv5 is finalized. The
goal was just to create something to see if it is doable (both GCC and
GDB seem to have nice datastructures already setup, so even for someone
like me without any prior knowledge of either program it was easy to
add) and give feedback on the proposal to see if it is worth it to adopt
for the next DWARF spec.
I'll think the answer is yes and I'll keep the patches around. So that
if there is a new DWARF standard version then we have an implementation
for the GNU toolchain as soon as it is final. But there isn't even a
first working draft at this point, just a bunch of proposals which might
or might not be adopted in their current or in some completely different
form. So these patches might not be integrated till next year.
For anything that does get integrated into GCC or GDB before DWARFv5 is
final we should certainly use a GNU vendor extension so that the rest of
the toolchain can easily adopt it. But that won't be possible in the
current form since DWARF type qualifier tags aren't vendor extensible.
And I don't know if anybody even needs it right now. Maybe if it is
useful for the GDB/GCC compiler expression effort we could create a GNU
vendor extension?
Cheers,
Mark
prev parent reply other threads:[~2014-06-23 21:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-22 10:25 Mark Wielaard
2014-06-23 16:27 ` Tom Tromey
2014-06-23 17:07 ` Mark Wielaard
2014-06-23 17:48 ` Pedro Alves
2014-06-23 18:00 ` Tom Tromey
2014-06-23 18:01 ` Eric Christopher
2014-06-23 21:34 ` Mark Wielaard [this message]
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=1403559239.3970.69.camel@bordewijk.wildebeest.org \
--to=mjw@redhat.com \
--cc=echristo@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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