My new plan is to post this by midnight Sunday my time, which is 9am Monday CET. (That means I'll post on Friday if I'm not expecting to do any work on the weekend.) This should let Petr see what my state is from the previous week/weekend as soon as he starts on Monday. I'd then like Petr to post by 9am Monday my time, which is 6pm CET. This should let me see as soon as I start on Monday what Petr's state is and what plans for the week he formed after seeing my report.
Much done since last report, far too little reporting:
Recent trunk work:
* 0.141 release including various fixes * some nit fixes on trunk since 0.141 * eu-readelf -N to speed up DWARF output back to pre-fancy levels
Recent dwarf branch work:
* reference tracker ** looked done-ish, but "two nits" Petr fixed were bugs that actually short-circuited all the fancy code ever running at all (I knew that was too easy!) With those fixed, it has a nice infinite recursion for circular reference chains. ** I've pushed some of the changes for getting smarter. ** Still working on it, unfinished changes on roland/tracker branch.
* collector ** I took a different tack on getting it from zero to limping. More unfinished work on roland/dwarf-collector branch.
This week:
Expected time spent on elfutils: 77%
* reference tracker ** make it right for dwarfcmp tests: fix circular refs ** optimize forward references
* collector ** Get to limping, then build collector from leaf types up.
Roland McGrath wrote:
My new plan is to post this by midnight Sunday my time, which is 9am Monday CET. (That means I'll post on Friday if I'm not expecting to do any work on the weekend.) This should let Petr see what my state is from the previous week/weekend as soon as he starts on Monday. I'd then like Petr to post by 9am Monday my time, which is 6pm CET. This should let me see as soon as I start on Monday what Petr's state is and what plans for the week he formed after seeing my report.
That works for me.
Apart from some inevitable unexpected fluff, I will spend this week fully on dwarf output. I don't see any isolated task that I could work on that doesn't collide with your work, so I'll try to figure out your unfinished writer and start adding code there. Perhaps we'll manage not to step on each others toes.
PM
Apart from some inevitable unexpected fluff, I will spend this week fully on dwarf output.
Great!
I don't see any isolated task that I could work on that doesn't collide with your work, so I'll try to figure out your unfinished writer and start adding code there. Perhaps we'll manage not to step on each others toes.
Right. There is no well-isolated task off hand, other than more reloc stuff, which I think should wait. My hope was to get dwarf_output quickly to a state where some bits that are somewhat isolated start to be doable.
The other thing you could do is look over the tracker code again, make sure the new code makes some sense and that you understand the circularity case. My test case is "src/dwarfcmp src/addr2line{,}" (circularity is not hard to come by). If you try the 47a586d tree (roland/tracker atm), it has some debug spew that should make some kind of sense. I expect that later today/tonight I will go over it again with some clean-up and comments and merge it onto the main dwarf branch. The circularity case seems to work now, but I really need to think it through again with a mind fresher than I had late Sunday night.
On dwarf_output proper, I mentioned "a new tack" but did not elaborate. The new approach I've taken on roland/dwarf-collector is to start with a dwarf_output that is mostly just like dwarf_edit, so it compiles and works. I've been factoring out some shareable pieces into dwarf_data, others have copied dwarf_edit->dwarf_output source code that is just a placeholder.
Where it is now is basically it is just like dwarf_edit, but I've jiggered the constructors from the top down so they pass the collector pointer. To start with, everything ignores the collector pointer and the actual construction is just like dwarf_edit::foo, but it passes the collector pointer down to the next level of constructor. In the 25c2399 tree (roland/dwarf-collector atm), this is all there down to attr_value, which ignores the collector.
The idea is to push this down to the attr_value dispatch object, so it passes the collector pointer to the value-space-specific constructors. I might get to that tonight.
From there, we can start doing real collector work from the leaves up.
That is, start with one attr_value flavor at a time and make those constructors use a value_set in the collector, etc. That should be some quasi-isolated fine-grained tasks to do each flavor of attribute.
Thanks, Roland
elfutils-devel@lists.fedorahosted.org