On Fri, 2010-08-06 at 15:21 -0700, Roland McGrath wrote: > > Yes, I saw that example. I need to figure out where/how this is handled > > in practice in the current scheme. Do you happen to have an actual > > example of when this kind of situation arises? > > See dwarf_tracker: dwarf_ref_tracker::reference_matched. > > The "plain vanilla circularity" was handled by the "We have a circularity > on the left-hand side." part. When the asymmetrical kind came up, I added > the "Our right-hand side is not in lock-step on a matching circularity." > part there.
The tracking through stack allocated tracker::reference_match structs which clear sets under investigation is sometimes a bit hard to follow. Especially to find the recursive step and how it relates to the actual die tree walking. I believe I only half understand how it works after staring at it for some time. > Where this came up was in dwarfcmp-test. That is, the comparison running > on an original dwarf reading a file vs a dwarf_output made from that. > I don't recall what file the first test case was, but it came up in some of > the files from the build itself, so 'make check' (run-dwarfcmp-test.sh) > hit it. The testwriter -T variants of this test fail with: terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct NULL not valid Because of the throw in entry_copier::populate > I can't get current GCC to do it in trivial cases off hand. But the > situation was that it would emit <pointer_type type=sameref/> several times > in the same CU. It might be that current GCC doesn't do that as much, but > I think it was happening in complex cases where it was sort of > "understandable". i.e., it might make sense that for those simple DIEs GCC > didn't keep track of having emitted them before. So what I'd say to try to > see it is play with dwarfcmp-test on src/* files (only the final links work > so far, not .o's). If you breakpoint or just comment out the whole second > part of the tracking in reference_matched (the part maintaining _m_active), > you should see the problem hit. Still running, it doesn't seem to trigger in any of the plain C self tests. > > It seems to me that if we can somehow embed/hash in the structure/cycles > > better the number of comparisons we need to do to find duplicate > > subgraphs should decrease a lot. But I probably need to do some more > > testing. What would be some good representative samples to look at? > > I don't know about representative. My methodology has been to start with > the all-C binaries in the elfutils build itself first. (Really that's just > what's easiest to put into 'make check'.) Second is vmlinux (I used my > random build, but you can get a whole one in any kernel-debuginfo rpm too), > which is also just "simple" C code, but sometimes more complex, and also a > good test in handling a zillion CUs. Mine seems to not be zillions, but "only" 1393 CUs. But how do you test such a beast? Are you actually able to run dwarfcmp on your vmlinuz and see it finish in any reasonable time? > Third is the C++ binaries in the > elfutils build (C++ DWARF is *way* more complex in reference graphs > usually), first dwarflint is a smaller one, then dwarfcmp is pretty hairy. And do any of these ever finish a dwarfcmp for you? I tried for a couple of hours, but never saw any of these larger C++ examples finish. Not even a "small" one like dwarflint. > Our testing plan (see wiki bits) is to use the entire history of Fedora and > RHEL debuginfo rpms as representative data. But that's for big test runs > once we are correctly handling all the local test data readily on hand. > > Beyond the really trivial cycles (like any linked-list struct type), > I have not found it very easy to come up with small sources that produce > more interesting DWARF graphs. But I haven't really tried all that hard. > I always just settled into some particular corner of weirdness in the > dwarflint or dwarfcmp binaries that I found by testing, and chugged away on > debugging handling those particular subtrees. > > If you have any luck coming up with hand-written C/C++ code that produces > more interesting DWARF trees for test cases, then I will certainly put some > time into making it easier to maintain those in the elfutils sources to be > used as test data for 'make check'. I'll try. If not possible with c/c++ examples having handwritten asm versions would be nice. Not having simple examples has been the most frustrating issue for me. Using anything non-trivial quickly makes me loose track of what I am really trying to figure out... Cheers, Mark _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
