Re: mjw/dwarf_output branch

[Roland McGrath <roland at redhat dot com>]

> But having all hashes (local and global) in pending_entry would be
> beneficial. Currently however we try to drop the pending_entry as soon
> as possible whenever we finalize an entry. So maybe we should move them
> both into entry. Also because entry already has the parent which is used
> in the tracker for the matching algorithm.

The die_info_pair is the place that makes sense to me for storing more
information about the final state of things.  That is, either in
dwarf_output::debug_info_entry or in die_info.  Those live permanently in
the collector.  That's where you benefit from having full hash values on
hand to compare, because when you need to do comparisons it's against
existing objects already final in the collector and found there via hashes.
If you had them in copier::entry, how would you ever find them there when
you need them?

die_info also has _m_parent, which is what's used by copier::tracker.

> Yes, again I admit that the way this evolved was mainly because of the
> way I was most easily able to change the code. Ideally I would have
> added the local hash code to the attributes themselves, but it seemed
> dwarf_data::value_reference, but I really couldn't figure out how things
> got initialized correctly in that case. And it wasn't clear to me
> whether the concept of local hashes really made much sense to any other
> subclass/template instance of that type. I'll make sure the final
> algorithm used for the hash calculation will be documented in the code.

It's certainly possible to do it the other way.  You just don't break up
the hash calculation along the lines of the attributes_type/children_type
objects.  Instead, do it all at the entry level.

> > As I did things originally, the dwarf_output::attr_value::reference method
> > (really dwarf_data::attr_value::reference) is not meant to be used on
> > something that isn't really final and placed.
> 
> I have to admit that I find this slightly confusing, since it seems to
> depend on which template instance is being used whether or not
> reference() works or not. Although I now see why that would be in the
> implementation. It kind of breaks the interface abstraction.

No, the interface abstraction is for objects whose construction has been
finished.  If you use dwarf_output::attr_value::reference on a dwarf_output
object that actually exists, then it works just fine.  It's only trying to
use that while you are still inside its own constructor that is a problem.

> Yeah, I actually had wanted to do a trick like that in the
> attributes_type do_hash () function, but I didn't know how to get at the
> _m_value of the attr_value there. Which is also why I ended up using
> what_space to detect whether the attribute was a reference value or not.

You can just use av->_m_value directly.  If you can't, then you just
have to add:
	friend class dwarf_output::attributes_type;
into the 'class attr_value' definition.

> I admit that my c++ typing knowledge fails me again in this example.
> How can it be that this template variant of reference () returns ...
> while the dwarf_data::attr_value::reference method is defined as
> inline const die_ptr &reference () const with typedef typename
> impl::debug_info_entry::pointer die_ptr; Since impl is dwarf_output, it
> seems somewhat curious that this method is allowed to change the type of
> the return value. Again this kind of breaks my vision of the abstraction
> interface.

You have the wrong idea of how the abstraction binding works.  A template
is not like a base class.  The various dwarf* classes are "template
compatible".  What that means is that you can use the methods of the same
names in the same ways.  Put another way, it means the same method in each
of two implementations will have return types that are template-compatible.

> No it didn't directly answer my question of "how the hell do I trick c++
> into doing what I want in this case", but it does show me I should
> concentrate on moving all (local) hashing logic into the (pending) entry
> which can rely on the input die tree and stay as far away from anything
> that could become part of pending_dwarf as I can for now :)

Well, I can't tell if we are really making progress here or not.
But I'll hope.


Thanks,
Roland