Re: [Valgrind-developers] vmware backdoor patch

[Sunny D. <int...@ya...>]

anybody?

-Not so Sunny...:(



----- Original Message -----
From: Sunny Das <int...@ya...>
To: Philippe Waroquiers <phi...@sk...>
Cc: "val...@li..." <val...@li...>
Sent: Friday, June 1, 2012 7:47 AM
Subject: Re: [Valgrind-developers] vmware backdoor patch

Looks like we will need to change Vg_ClientRequest to add CLIENT_CALL4 and then just provide the CALL4 version of VALGRIND_NON_SIMD_CALLx.

It also looks like it will be hard to go beyond 4 args. Is this doable?

-Stay Sunny!

--- On Fri, 6/1/12, Sunny Das <int...@ya...> wrote:

> From: Sunny Das <int...@ya...>
> Subject: Re: [Valgrind-developers] vmware backdoor patch
> To: "Philippe Waroquiers" <phi...@sk...>
> Cc: "val...@li..." <val...@li...>
> Date: Friday, June 1, 2012, 7:10 AM
> >
> VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function,
> > args ...);
> 
> The max version of this macro allows 3 args. The vmware
> backdoor needs 4 args. Is it possible to extend this to
> 4,5,6 args easily?
> 
> -Stay Sunny!
> 
> --- On Wed, 5/30/12, Philippe Waroquiers <phi...@sk...>
> wrote:
> 
> > From: Philippe Waroquiers <phi...@sk...>
> > Subject: Re: [Valgrind-developers] vmware backdoor
> patch
> > To: "Sunny Das" <int...@ya...>
> > Cc: "val...@li..."
> <val...@li...>
> > Date: Wednesday, May 30, 2012, 11:30 AM
> > On Wed, 2012-05-30 at 08:09 -0700,
> > Sunny Das wrote:
> > > The patch still seems to apply (after some
> path/file
> > renaming) but it does not build. That answers my
> original
> > question. But it raises a new one:
> > > 
> > > Is anyone planning on fixing and merging that
> patch
> > in?
> > I have 0+epsilon intention to work on this patch,
> > the epsilon is to cover the unlikely case the vmware
> would
> > donate
> > 1_000_000 (1 million) dollars to support Valgrind
> > development :).
> > 
> > (the patch is many lines, only to support vmware
> specific
> > things,
> > not clear how to test thist, etc).
> > So, does not look very attractive to me.
> > 
> > 
> > Why not rather do that at "user level" ?
> > (i.e. in the vmware code or libraries, do something
> like:
> > 
> >    if (RUNNING_ON_VALGRIND)
> >      
> >
> VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function,
> > args ...);
> >    else
> >      
> > do_the_real_thing_on_the_real_cpu_function (args);
> > 
> > Looks to me this should have the effect desired,
> without
> > introducing
> > hundreds of vmware backdoor thingies in Valgrind.
> > 
> > Philippe
> > 
> > 
> > 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and 
> threat landscape has changed and how IT managers can
> respond. Discussions 
> will include endpoint security, mobile security and the
> latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers