Re: [Valgrind-developers] [PATCH] Valgrind for PowerPC

[Paul M. <pa...@sa...>]

Nicholas Nethercote writes:

> - Could you write up a description of the main changes you made, which
>   parts were affected a lot, which parts weren't affected much, anything
>   you've learnt?  No substitute for reading the entire patch, but valuable
>   as a high-level introduction.

I'll do that, tonight hopefully.

> - Some big changes have been made ("full virtualization") since 2.1.0.  I
>   don't know how much these changes would affect your patch.

I'll check out the cvs repository on sourceforge.net and look at what
has changed.  I assume that sourceforge.net is the right place to go?

> - How much have you tested it?  Does it run big programs like OpenOffice
>   and Mozilla?  Does it pass all the regression tests?  ("make regtest")

Not yet, still working on that.

>   Julian, Jeremy and I have given quite a lot of thought to architecture
>   ports.  The key requirement, in our minds, is that we don't want an NxM
>   code explosion, where N is the number of architectures, and M is the
>   number of skins.  (Also, factor in a xP for P different operating
>   systems.)  With the "fat UCode" approach you've taken, you unfortunately
>   have this problem, as you've seen with all the skin changes that were
>   required.

Mostly in the memcheck skin.  I think that with the other skins, we
could avoid the need for changes in the skins with some suitable
abstractions.  (I can see one exception to that though: the code in
cachegrind that works out what the cache parameters are.)

>   Finding a design that supports multiple architectures without requiring
>   skin rewriting is extremely challenging.  We have a Wiki
>   (www.goop.org/twiki/bin/view/Valgrind/ValgrindFutures) where we've
>   discussed various things.  Much of it is 6--9 months old, and a bit out
>   of date.  But the "IrKnowledge" and "IrOpinions" pages show some of our
>   current thinking;  they are a distillation of several failed
>   half-attempts to come up with a concrete design.

Interesting.  If we allow skins to extend the ucode then we will
inevitably have architecture-specific code in the skins.  We could
import the ucode extensions from memcheck into the core and then not
allow skins to extend the ucode.  That shouldn't be too bad since
skins can always use CCALL to do any funky stuff they need to do.
Memcheck is a bit of a special case since it is the "primary" skin and
because it is important that the valid bit computations are reasonably
fast.  For that reason I wouldn't like to see all the tag computations
done as CCALLs.  Some of them could be done with ordinary ucode
instructions (e.g. AND, OR) but some of them couldn't be done easily
and efficiently that way (e.g. Tag_PCast40).

>   So I'm personally not convinced the approach you've taken is the right
>   way to go -- it might be acceptable for two architectures, but what
>   happens when someone wants a SPARC port, or an ARM port, etc?
>   Obviously there must be some architecture-specific bits (eg. asm
>   disassembly and code-regeneration), but keeping those bits separate from
>   the skins seems, to me, crucial.

I agree that that is the direction to head.  Valgrind is such a useful
tool though that I want to have something that is usable on PPC now,
without having to wait until we have worked out the exact right way to
do things. :)

> As a first step, would you be interested in bundling it up (with "make
> dist") and putting it somewhere so people can try it?  I can link to it
> from the Valgrind page.

Good idea.  I have put it at

http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2

This includes a fixes for a couple of bugs I found last night.

Regards,
Paul.