From: Julian Seward Date: Mon, 31 Aug 2015 14:24:14 +0000 (+0000) Subject: Revisit r15601 (Change the --smc-check default value to =all-non-file.) X-Git-Tag: svn/VALGRIND_3_11_0~55 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5582e3a511620a6d2f914a553e4d7617ef7eaf54;p=thirdparty%2Fvalgrind.git Revisit r15601 (Change the --smc-check default value to =all-non-file.) to restrict the change to those architectures that do provide automatic D-I coherence (x86, amd64, s390x). This commit restores the default value for all other architectures back to its pre r15601 state, so as not to burden those architectures unnecessarily with =all-non-file. Also, this rewrites the relevant manual section. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15602 --- diff --git a/coregrind/m_options.c b/coregrind/m_options.c index b9b7b17c70..4cf2d1036a 100644 --- a/coregrind/m_options.c +++ b/coregrind/m_options.c @@ -129,13 +129,26 @@ UInt VG_(clo_max_threads) = MAX_THREADS_DEFAULT; Word VG_(clo_main_stacksize) = 0; /* use client's rlimit.stack */ Word VG_(clo_valgrind_stacksize) = VG_DEFAULT_STACK_ACTIVE_SZB; Bool VG_(clo_wait_for_gdb) = False; -VgSmc VG_(clo_smc_check) = Vg_SmcAllNonFile; UInt VG_(clo_kernel_variant) = 0; Bool VG_(clo_dsymutil) = False; Bool VG_(clo_sigill_diag) = True; UInt VG_(clo_unw_stack_scan_thresh) = 0; /* disabled by default */ UInt VG_(clo_unw_stack_scan_frames) = 5; +// Set clo_smc_check so that it provides transparent self modifying +// code support for "correct" programs at the smallest achievable +// expense for this arch. +#if defined(VGA_x86) || defined(VGA_amd64) || defined(VGA_s390x) +VgSmc VG_(clo_smc_check) = Vg_SmcAllNonFile; +#elif defined(VGA_ppc32) || defined(VGA_ppc64be) || defined(VGA_ppc64le) \ + || defined(VGA_arm) || defined(VGA_arm64) \ + || defined(VGA_mips32) || defined(VGA_mips64) \ + || defined(VGA_tilegx) +VgSmc VG_(clo_smc_check) = Vg_SmcStack; +#else +# error "Unknown arch" +#endif + #if defined(VGO_darwin) UInt VG_(clo_resync_filter) = 1; /* enabled, but quiet */ #else diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index 3a9e720c40..b8d1f577c0 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -1704,60 +1704,60 @@ need to use them. - + This option controls Valgrind's detection of self-modifying - code. If no checking is done, if a program executes some code, then - overwrites it with new code, and executes the new code, Valgrind will - continue to execute the translations it made for the old code. This - will likely lead to incorrect behaviour and/or crashes. - - Valgrind has four levels of self-modifying code detection: - no detection, detect self-modifying code on the stack (which is used by - GCC to implement nested functions), detect self-modifying code - everywhere, and detect self-modifying code everywhere except in - file-backed mappings. - - Note that the default option will catch the vast majority - of cases, including the case where a JIT - compiler dynamically generates code and - subsequently overwrites part or all of it. Running with - all will slow Valgrind down noticeably. - Running with - none will rarely speed things up, since very little - code gets dynamically generated in most programs. The - VALGRIND_DISCARD_TRANSLATIONS client - request is an alternative to - and - that requires more programmer effort but allows Valgrind to run - your program faster, by telling it precisely when translations - need to be re-made. - - - + code. If no checking is done, when a program executes some code, then + overwrites it with new code, and executes the new code, Valgrind will + continue to execute the translations it made for the old code. This + will likely lead to incorrect behaviour and/or crashes. + For "modern" architectures -- anything that's not x86, + amd64 or s390x -- the default is stack. + This is because a correct program must take explicit action + to reestablish D-I cache coherence following code + modification. Valgrind observes and honours such actions, + with the result that self-modifying code is transparently + handled with zero extra cost. + For x86, amd64 and s390x, the program is not required to + notify the hardware of required D-I coherence syncing. Hence + the default is all-non-file, which covers + the normal case of generating code into an anonymous + (non-file-backed) mmap'd area. + The meanings of the four available settings are as + follows. No detection (none), + detect self-modifying code + on the stack (which is used by GCC to implement nested + functions) (stack), detect self-modifying code + everywhere (all), and detect + self-modifying code everywhere except in file-backed + mappings (all-non-file). + Running with all will slow Valgrind + down noticeably. Running with none will + rarely speed things up, since very little code gets + dynamically generated in most programs. The + VALGRIND_DISCARD_TRANSLATIONS client + request is an alternative to + and + that requires more programmer effort but allows Valgrind to run + your program faster, by telling it precisely when translations + need to be re-made. + + provides a - cheaper but more limited version - of . It adds checks to any - translations that do not originate from file-backed memory - mappings. Typical applications that generate code, for example - JITs in web browsers, generate code into anonymous mmaped areas, - whereas the "fixed" code of the browser always lives in - file-backed mappings. - takes advantage of this observation, limiting the overhead of - checking to code which is likely to be JIT generated. - - Some architectures (including POWER/PPC, ARM and MIPS) - require programs which create code at runtime to flush the - instruction cache in between code generation and first use. - Valgrind observes and honours such instructions. Hence, on - those targets, Valgrind always provides - complete, transparent support for self-modifying code. It is - only on platforms such as x86/Linux, AMD64/Linux, x86/Darwin, - AMD64/Darwin and S390/Linux that you need to use this option. + cheaper but more limited version + of . It adds checks to any + translations that do not originate from file-backed memory + mappings. Typical applications that generate code, for example + JITs in web browsers, generate code into anonymous mmaped areas, + whereas the "fixed" code of the browser always lives in + file-backed mappings. + takes advantage of this observation, limiting the overhead of + checking to code which is likely to be JIT generated.