This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: entry vs pending_entry in dwarf_output::copier


Hi Roland,

> Because of the aforementioned memory consumption, we will want to do
> early finalization during the first copying walk whenever possible.
> That is, do the "second walk" work for any subtree that has no
> references to other entries that are not yet final.
> 
> Is that all clear? I'm not sure it's entirely necessary wrap one's
> head
> around all the hairy bookkeeping of the current plan. The new plan is
> replacing it with something easier to understand anyway.

Yes, things are more clear now. Thanks. And dropping the pending_entry
asap to safe memory also makes sense. But is the state held separately
in pending_entry really that much and/or can't it just be derived from
entry itself? It is somewhat hard to change the hairy bookkeeping without
understanding how it currently works.

The reason I am looking at this is indeed to see if it can be simplified.
If I am looking at this right then if we move the dwarf_output
attribute_map held in pending_entry to entry, and we derive
the children from the identities held in the _m_entries map, then it seems
we have all needed state. But I might be missing some of the other purposes
of pending_entry like the usage in pending_dwarf comparator. See below.
 
> There will still be some hairy magic for cases of circular references.
> An entry can't be truly final until all its references are final, and
> thus that's a circular requirement. That's why we need the "placed"
> stage, where a value_reference already in the collector gets reified
> with the actual iterator into its referent's parent's children vector.

As far as I understand the circular references are constructed to be
used in the pending_dwarf comparison. Again, I am hoping we can get rid of
that and do the comparison on the original input die tree when we need to
compare two entries (since we do/should have the references to the original
tree for both and if attributes are similar in the original trees, they
should be equal in the newly constructed dwarf_output tree), instead of
doing them on the pending tree (and again I might be missing why that is
impossible).

Cheers,

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]