Notify valgrind when we modify code on x86.

Notify valgrind when we modify code on x86.

On platforms valgrind supports, some straight line assembly will be emitted in FlushICache, which valgrind will see.

You can read more about the cache / api here:
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
http://valgrind.org/docs/manual/faq.html#faq.java

[Dean McNamee, 2008-12-07 16:53:12]

Another option would be some -DUSE_VALGRIND_BLAH, although that ends up being a
pain to propagate through the chromium build...

[iposva, 2008-12-08 04:44:21]

Dean,

In general I think the ability to use tools like valgrind is essential, but I
would strongly prefer a -DENABLE_VALGRIND flag to wrap the valgrind related
code. I do understand that it is hard to pass this down through the Chromium
build layers, but this is a feature that needs to be addressed at some time
anyway. In the meantime I would suggest you address this short-coming by setting
the macro in the scons file for the one platform where you care about valgrind
support, since currently two out of our three ia32-based platforms do not
support valgrind (Windows and Mac OS X).

Also you need to make sure that the license in the valgrind.h file is acceptable
for us to include it in src/third_party.

Cheers,
-Ivan

[Dean McNamee, 2009-03-26 15:44:31]

I think this code should be cheap enough to always have it run, even in release.
 I will get back with some numbers on how much it speeds up valgrind, since we
should now be able to safely run with --smc-check=none.  I will also have to
update the build files, etc.

On 2008/12/08 04:44:21, iposva wrote:
> Dean,
> 
> In general I think the ability to use tools like valgrind is essential, but I
> would strongly prefer a -DENABLE_VALGRIND flag to wrap the valgrind related
> code. I do understand that it is hard to pass this down through the Chromium
> build layers, but this is a feature that needs to be addressed at some time
> anyway. In the meantime I would suggest you address this short-coming by
setting
> the macro in the scons file for the one platform where you care about valgrind
> support, since currently two out of our three ia32-based platforms do not
> support valgrind (Windows and Mac OS X).
> 
> Also you need to make sure that the license in the valgrind.h file is
acceptable
> for us to include it in src/third_party.
> 
> Cheers,
> -Ivan

[Dean McNamee, 2009-07-20 12:28:51]

Timur reports that this patch (and not having to specify --smc-check=all) cuts
10-15% off some of the chrome tests running under valgrind.

I cleaned up the patch.  I think the instrumentation code should be fast enough
to keep even in release (and without any special defines), but we'll have to
watch the numbers and decide what to do...

[Dean McNamee, 2009-07-22 09:36:07]

Timur, do you have numbers from the v8 benchmark (release build, not running
under valgrind) for before / after?

Thanks

On 2009/07/20 12:28:51, Dean McNamee wrote:
> Timur reports that this patch (and not having to specify --smc-check=all) cuts
> 10-15% off some of the chrome tests running under valgrind.
> 
> I cleaned up the patch.  I think the instrumentation code should be fast
enough
> to keep even in release (and without any special defines), but we'll have to
> watch the numbers and decide what to do...

[iposva, 2009-07-23 18:01:57]

Please also identify what happens on other platforms when compiled with gcc.

-Ivan

http://codereview.chromium.org/13612/diff/4401/4403
File src/ia32/cpu-ia32.cc (right):

http://codereview.chromium.org/13612/diff/4401/4403#newcode31
Line 31: #include "third_party/valgrind/valgrind.h"
The code in valgrind.h does not appear to distinguish between more than Linux
and AIX. I assume that the above test for __GNUC__ is intended to check for gcc
compilation to filter out Windows. But what happens if you compile with this
header on Windows using gcc or on Mac OS X?

[Dean McNamee, 2009-07-24 10:00:01]

Hey Ivan,

I think compiling it on Windows under GCC should be fine. The only reason to
check for GCC is because the inline assembly is in gcc syntax.  valgrind.h does
a bunch of checks for the processor type (x86, x86-64, ppc), and the macro
shouldn't be defined if we're on a CPU that valgrind doesn't support.

[Dean McNamee, 2009-08-10 17:53:12]

Poke...

On 2009/07/24 10:00:01, Dean McNamee wrote:
> Hey Ivan,
> 
> I think compiling it on Windows under GCC should be fine. The only reason to
> check for GCC is because the inline assembly is in gcc syntax.  valgrind.h
does
> a bunch of checks for the processor type (x86, x86-64, ppc), and the macro
> shouldn't be defined if we're on a CPU that valgrind doesn't support.

[Mads Ager (chromium), 2009-08-11 15:24:30]

I have submitted this patch as it appears to not have a negative impact on
performance.  I will watch performance closely and revert again if I notice a
performance regression because of this change.

On 2009/08/10 17:53:12, Dean McNamee wrote:
> Poke...
> 
> On 2009/07/24 10:00:01, Dean McNamee wrote:
> > Hey Ivan,
> > 
> > I think compiling it on Windows under GCC should be fine. The only reason to
> > check for GCC is because the inline assembly is in gcc syntax.  valgrind.h
> does
> > a bunch of checks for the processor type (x86, x86-64, ppc), and the macro
> > shouldn't be defined if we're on a CPU that valgrind doesn't support.

[Timur Iskhodzhanov, 2009-10-21 10:21:40]

Sorry, I was applying the annotations the wrong way for amd64. With properly
applied annotations AND your VEX patch everything works fine.

[Timur Iskhodzhanov, 2009-10-21 10:23:01]

Oooops sorry, posted to the wrong issue...

Regarding this patch: we need to apply patch similar to src/ia32/cpu-ia32.cc to
src/x64/cpu-x64.cc