This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: sharing_stack
- From: Petr Machata <pmachata at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 07 Dec 2010 18:33:22 +0100
- Subject: Re: sharing_stack
07.12.2010 00:57, Roland McGrath wrote:
> If you think your sharing_stack fix makes it good, then
> s/stackish/sharing_stack/ in dwarf and dwarf_tracker. That's the only way
> to get the code back in use. Doing so should reduce the memory footprint
> of dwarfcmp (and some of dwarf_output stuff) by a lot, and maybe help CPU
> use too. If that works without new regressions or strangeness, then it's
> all good.
I turned it on. I did a couple tests (dwarfcmp X X for several Xs of
various sizes, but none really huge) and got no leaks or crashes (or
memory warnings in valgrind).
I'm doing make check now, one core is spinning on "dwarf" branch and has
been like that for about four hours now. It's stuck on "dwarfcmp
dwarfcmp dwarfcmp".
The other core checks "roland/dwarf-hacking" with the sharing_stack
fixes applied on top. That one got through all the "dwarfcmp" tests,
then there's a bunch of failures due to "dwarfcmp-test" throwing
std::logic_error (these are not new), and now it's stuck on
"dwarfcmp-test dwarfcmp dwarfcmp". Apparently the DIE graph of dwarfcmp
is a nasty case. I cross-checked on a beefy machine with stackish
instead of sharing_stack, and it gets stuck the same way, so that's not
either.
All in all, I'm inclined to vouch for that fix.
PM