This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCHv4] Enable -fsanitize-recover for KASan


On Fri, Oct 24, 2014 at 11:50:58AM +0200, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote:
> > I am somewhat lost in this thread and probably missing something.
> > But why do we need __asan_load (which is not noabort) at all? Outline
> > instrumentation is non a default mode for both user-space asan and
> > kasan (at least in the envisioned future). I would expect that these
> > non-typical cases that use outline instrumentation can also bear the
> > overhead of non-noreturn functions. Can we use just one version of
> > __asan_load and let runtime decide on abort?
> 
> __asan_load actually must never be noreturn, because in the common
> case where the load is valid it of course returns.

The point of __asan_load*_noabort (vs. __asan_load*) and
__asan_report*_noabort (vs. __asan_report*) is to allow the choice
what is fatal and what is not fatal to be done at compile time,
per compilation unit.  For __asan_report* that is a must, as __asan_report*
without noabort is noreturn, for __asan_load* which is not noreturn
the implementation can of course choose not to make something fatal when it
wishes.  Without -fsanitize-recover={address,kernel-address} support,
the choice could be done only per program or kernel globally, without a way
for programmer to differentiate.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]