|
From: Julian S. <js...@ac...> - 2005-03-23 14:07:55
|
This is a request for comments.
I'm thinking about getting rid of Addrcheck. Originally I made
Addrcheck as an experiment to see how much faster/smaller Memcheck
would be without all the V-bit stuff, and parked it in the repo.
=46rom the point of view of "here's an interesting hack" that's
fine. But that was then and this is now. Now I'm more interested
in looking at things the point of view of "how do we minimise our=20
long-term maintenance burden". It seems to me Addrcheck isn't worth
retaining:
* Addrcheck itself needs maintenance.
* There's a load of stuff shared between Addrcheck and Memcheck.
Although this factoring was done admirably well, it's still
extra complexity to have to deal with.
* The real killer is that I bet practically nobody uses Addrcheck.
Memcheck tells us everything Addrcheck does, and much more
besides.
* The performance motivations for Addrcheck turned out not to be
as convincing as first hoped:
- it isn't a whole lot faster than Memcheck. Memcheck's V bit
stuff is all done in-line, which is relatively quick. Both
of them have to call out to helpers to deal with loads/stores,
and that's the slow bit.
- we're learning that with a bit of care, it's possible to
reduce -- possibly drastically reduce -- Memcheck's memory
consumption without changing its behaviour.
To put this in perspective, currently the shadow memory machinery
in Memcheck only works on 32-bit little endian platforms. I've=20
been musing on how to fix it to be good for any combination of=20
32/64-bitness and little/bigendian-ness. That's additional
complication which I'd prefer not to have to do for both=20
Memcheck and Addrcheck.
Comments?
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-23 18:17:32
|
Julian Seward wrote:
>* The real killer is that I bet practically nobody uses Addrcheck.
> Memcheck tells us everything Addrcheck does, and much more
> besides.
>
>* The performance motivations for Addrcheck turned out not to be
> as convincing as first hoped:
>
> - it isn't a whole lot faster than Memcheck. Memcheck's V bit
> stuff is all done in-line, which is relatively quick. Both
> of them have to call out to helpers to deal with loads/stores,
> and that's the slow bit.
>
> - we're learning that with a bit of care, it's possible to
> reduce -- possibly drastically reduce -- Memcheck's memory
> consumption without changing its behaviour.
>
>
When I've been training people to use Valgrind, I generally recommend
they use addrcheck first, and then move to memcheck once addrcheck is
quiet. This is for one big reason: addrcheck is much easier to understand.
If addrcheck generates a message it is almost certainly a bug, and it
explains everything which needs fixing right there. There's hardly any
need for deep analysis, and it almost never generates false positives.
I can say with confidence that every message represents a core-dump
avoided by dumb luck, and it needs fixing. I only recommend memcheck
once addrcheck is clean, or if the bug seems more elusive. By then
they're used to working with Valgrind, parsing the messages, etc, and
are in a better state to deal with memcheck's subtleties.
Also, our target hardware is pretty slow and memory constrained, which
magnifies addrcheck's performance advantage.
>To put this in perspective, currently the shadow memory machinery
>in Memcheck only works on 32-bit little endian platforms. I've
>been musing on how to fix it to be good for any combination of
>32/64-bitness and little/bigendian-ness. That's additional
>complication which I'd prefer not to have to do for both
>Memcheck and Addrcheck.
>
Once you've solved it for memcheck, surely the same solution would apply
to addrcheck? Or is it a question of complex implementation? Couldn't
that be shared? I would have thought Vex would make it easier to share
the implementation, and compose various pieces of instrumentation
generation from smaller parts.
J
|
|
From: Robert W. <rj...@du...> - 2005-03-23 18:30:26
|
Could addrcheck and memcheck be rolled into one? In other words, a "quiet" version of memcheck that produces only what reports addrcheck would produce? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-03-24 02:09:52
|
On Wed, 23 Mar 2005, Robert Walsh wrote: > Could addrcheck and memcheck be rolled into one? In other words, a > "quiet" version of memcheck that produces only what reports addrcheck > would produce? I like this idea. But I think the key thing is that currently Addrcheck uses much less address space than Memcheck. Indeed, most of the Addrcheck-only code deals with the differently laid-out secondary maps. This is important, especially with the address space layout problems we still sometimes have. If we can get Memcheck's memory usage down as we've discussed, then I think we should do something like this. N |
|
From: Oswald B. <os...@kd...> - 2005-03-23 18:32:58
|
On Wed, Mar 23, 2005 at 10:17:27AM -0800, Jeremy Fitzhardinge wrote: > Couldn't that be shared? > taking this to the extreme, possibly close-to-impossible: would it be possible to create a(n efficient) tool stacking architecture? this would sort of resolve the addrcheck vs. memcheck question (by making memcheck addrcheck + initcheck). this might also be interesting in conjunction with "unrelated" tools, as sometimes there are correlations between bugs of different classes. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@cs...> - 2005-03-24 02:29:52
|
On Wed, 23 Mar 2005, Oswald Buddenhagen wrote: > taking this to the extreme, possibly close-to-impossible: would it be > possible to create a(n efficient) tool stacking architecture? this would > sort of resolve the addrcheck vs. memcheck question (by making memcheck > addrcheck + initcheck). this might also be interesting in conjunction > with "unrelated" tools, as sometimes there are correlations between bugs > of different classes. Possible? Probably. I deliberately didn't design for this possibility when I did the core/tool modularisation because the cost/benefit ratio would be really high. N |
|
From: Donna R. <do...@te...> - 2005-03-23 18:34:16
|
On Wednesday 23 March 2005 18:17, Jeremy Fitzhardinge wrote: > When I've been training people to use Valgrind, I generally recommend > they use addrcheck first, and then move to memcheck once addrcheck is > quiet. This is for one big reason: addrcheck is much easier to understand. Totally agree. > If addrcheck generates a message it is almost certainly a bug, and [large snip] My 10 cents worth: rather than maintaining two such similar tools, give memcheck a flag "--naive" or some such, which makes it behave a la addrcheck, ==> everyone happy. de |
|
From: Jeremy F. <je...@go...> - 2005-03-24 02:55:37
|
Nicholas Nethercote wrote:
> This is important, especially with the address space layout problems
> we still sometimes have. If we can get Memcheck's memory usage down
> as we've discussed, then I think we should do something like this.
I think there's some more scope for factoring out the secondary map
code. Pretty much all the tools which have shadow memory copy
memcheck's primary/secondary map code; it would be nice if they could
share this in some way.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-24 03:37:30
|
On Wed, 23 Mar 2005, Jeremy Fitzhardinge wrote: > I think there's some more scope for factoring out the secondary map > code. Pretty much all the tools which have shadow memory copy > memcheck's primary/secondary map code; it would be nice if they could > share this in some way. I've tried to factor out this commonality before, and failed. I'd love to see someone else succeed at it. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-24 02:31:40
|
On Wed, 23 Mar 2005, Julian Seward wrote: > * The real killer is that I bet practically nobody uses Addrcheck. > Memcheck tells us everything Addrcheck does, and much more > besides. The December 2003 survey pegged Addrcheck usage at about 6% of all usage. Memcheck was at 85%. The surveys I've receved then (about 15) indicate pretty similar usage levels. N |