Re: [PATCH] DWARFv5. Handle DW_TAG_atomic_type _Atomic type modifier.

[Mark Wielaard <mjw@redhat.com>]

On Mon, 2014-06-23 at 10:27 -0600, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mjw@redhat.com> writes:
> 
> Mark> This prototype patch matches the experimental patch to GCC:
> Mark> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01677.html
> 
> Thanks, Mark.
> 
> Mark> Since there is not even a draft of DWARFv5 I don't recommend adopting
> Mark> this patch. All details may change in the future. I am mainly doing it
> Mark> to give better feedback on the DWARFv5 proposals (in this case the
> Mark> feedback would be that it is unfortunate we cannot easily do this as a
> Mark> vendor extension with DW_TAG_GNU_atomic_type since that would break
> Mark> backward compatibility).
> 
> I don't understand this bit.  It's reasonably normal to add a new GNU tag.

It is certainly reasonable to add new vendor attributes or tags, but
only for "independent" tags or attributes that consumers can easily
ignore if they aren't recognized. There is no mechanism for introducing
new vendor type qualifier tags like these in DWARF. The issue is that a
consumer cannot detect that a tag is just a type qualifier which can be
ignored if not recognized (all type qualifiers do use DW_AT_type to
point to the underlying type, but so do other non-qualifier tags that
have completely different semantics). So if we would add a vendor tag
and GCC starts annotating/wrapping other type tags with
DW_TAG_GNU_atomic_type then consumers will start failing to find the
underlying type (I already had to patch up various consumers when I
added DW_TAG_restrict_type, which has been standard since DWARFv3). So
if we would introduce a vendor extension to mark atomic types, then it
would have to work differently from the proposed type qualifier tag.

> Mark> Is there a recommended way for doing/keeping these kind of
> Mark> speculative patches?
> 
> Just hosting it on a public git somewhere.  I suppose we could resurrect
> archer.git, though there are plenty of hosting services now.

OK, I can host a repo on my own server or on gitorious. I was just
hoping there was some generic GDB way to host these works in progress,
so others know this is being worked on with the intention of being
merged eventually. I am afraid that if everybody starts hosting their
own repos at various places it will be harder for people to know which
active development is ongoing.

> Some nits follow.  The patch looks good overall.

Thanks. I'll fix the issues and post when I find a good way to host my
repo.

Cheers,

Mark