PATCH: Making the DWARF constants type-safe

[David Blaikie]

On Mon, Oct 21, 2013 at 10:15 AM, Eric Christopher <echristo at gmail.com>wrote:

> On Mon, Oct 21, 2013 at 9:53 AM, David Blaikie <dblaikie at gmail.com> wrote:
> > After spending some time parallel debugging Clang and GCC I've been
> > frustrated by Clang's use of raw integer types for form/tag/etc
> (compared to
> > GCC which uses specific enum types for those variables - making it
> easier to
> > print their textual or integer values as needed, rather than only the
> > integer values).
> >
> > To improve this, here's a patch that separates out the dwarf constants
> into
> > separate groups, named the same as GCC's (for want of any better names)
> and
> > uses them in the lib/CodeGen/AsmPrinter Dwarf handling code.
> >
> > Probably the major debatable portion of this is how we handle DWARF
> blocks.
> > They're treated as DIEs and have attributes added to them. Generally
> those
> > attributes have no attribute type (using zero) - since that's not a valid
> > DWARF attribute kind number the code didn't compile anymore. I could've
> > added casts all over the place but instead opted to put a few wrapper
> > functions to make it a bit more type safe - such that the attribute can
> be
> > omitted for certain 'add' operations but only if the DIE is actually a
> > block.
> >
> > I don't really know enough to understand whether it makes sense for
> blocks
> > to be DIEs or how we should handle their attributes not having attribute
> > types here, so I figured I'd throw this out there in case I'm missing
> > something here.
>
> I don't really know that blocks need to be DIEs, mostly they want to
> be tuples/lists of some sort. We're just using DIEs to represent the
> "it's a form and a length and some stuff".
>

OK - I'll keep that in mind for the future.


> It's a great step though so thanks.
>

Thanks - committed as r193091.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131021/93ed85c9/attachment.html>