[PATCH] D17321: DIEData, DIEWriter: introduce and begin migration.

[Peter Collingbourne via llvm-commits]

On Sun, Feb 21, 2016 at 04:47:06PM -0800, David Blaikie wrote:
> On Fri, Feb 19, 2016 at 8:08 PM, Eric Christopher via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> 
> >
> >
> > On Fri, Feb 19, 2016 at 7:45 PM Robinson, Paul <
> > Paul_Robinson at playstation.sony.com> wrote:
> >
> >> You know I favor the pedantic answer. J  The point remains, type unit
> >> signatures need to be content-dependent and dwo_ids really don't,
> >> regardless of the details, because they have different consistency
> >> requirements.
> >>
> >>
> > Where content dependent can mean a lot of things :)
> >
> > That said, I really wish I could remember the dwo_id reasoning for using
> > the hash for type units rather than a simple hash of the section.
> >
> 
> One reason that sprung to my mind is type units themselves - the hash of
> the debug_info section would be insufficient to capture the change in the
> content of a type. Eg:
> 
> struct foo { int i; };
> foo f;
> 
> With type units enabled, would produce the same hash if you make the int a
> float instead.
>
> So you'd at least have to hash the content of the types as well (but
> perhaps you could hash the whole debug_types section instead of the
> content-aware hashing)

I believe so. I guess in your example it's possible that the offset into
debug_str (the DW_TAG_base_type's DW_AT_name attribute) would not change,
so we'd have to hash debug_str as well.

> So that's a best-guess right now: we didn't have the bytes in memory to
> just hash, and we didn't want to use a frontend-provided identifier because
> that would be needlessly volatile (comment changes would purturb it, etc -
> you only want a hash of what ends up in the debug info, not more than
> that). So it's possible that we can hash the bytes before we emit them and
> patch them up (having the bytes in memory first isn't the end of the world
> - LLVM's MC API currently does that anyway, so we can't avoid that by
> streaming it out - but it dose double that requirement unless/until we
> improve LLVM's MC APIs)

Yes, as I alluded to in an earlier message I'd like to add an API to MC that
essentially would let you move bytes and fixups (essentially the contents
of MCDataFragment) into the MC layer. The MCAsmStreamer implementation of
this would essentially loop over the fixup list and do something similar to
the loop in DIEData::emit in my patch.

Thanks,
-- 
Peter