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: 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

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