This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.
- From: Yury Gribov <y dot gribov at samsung dot com>
- To: Martin LiÅka <mliska at suse dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 11 May 2016 17:29:04 +0300
- Subject: Re: [PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.
- Authentication-results: sourceware.org; auth=none
- References: <57333E07 dot 3060404 at suse dot cz>
On 05/11/2016 05:13 PM, Martin LiÅka wrote:
Hello.
It's bit confusing for a use that -fsanitize-recover=address does not recover
an instrumented binary. As a default value of halt_on_error is set to 0 for address sanitizer,
the binary fails on a first error.
I'm the guy behind -fsanitize-recover=address so let me explain.
Error recovery requires changes both to compiler (insert calls to
recovering __asan_report_error_X_noabort rather than noreturning
__asan_report_error_X) and runtime (do not abort when detecting overflow
inside intercepted API like memcpy). -fsanitize-recover controls the
compiler side, whereas halt_on_error=0 controls the runtime side.
Unfortunately currently there is no way to inform runtime library that
compiled code would like it to continue execution after detecting error.
Actually it's not clear how to do that properly because different parts
of application could be compiled with different recovery settings (e.g.
a.c with recovery and b.c without) making it hard to understand what
behavior user would expect from runtime library interceptors.
Following patch attempts to explain the ENV variable.
Ready for trunk?
LGTM (but I'm not a maintainer and do not have approve right).
Thanks,
Martin