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: [PATCH 0/17] KASan 4.9 backport


On 10/17/2014 04:12 PM, Jakub Jelinek wrote:
I had a brief look at what ended up on the branch in the end, and
from what I understand, the 4.9 libasan.so has
__asan_report_store_n and __asan_report_load_n entry points, but does
not have any __asan_loadN/__asan_reportN entrypoints (neither 1/2/4/8/16,
nor variable).
So, what the branch does seems to not match what the library provides.

I agree, __asan_report_loadN is indeed there and misalign tests seem to pass fine. Probably I should have examined 4.9 libasan closer.

With -fsanitize=address -O2 --param asan-instrumentation-with-call-threshold=0
foo is again unexpectedly not instrumented, and bar is instrumented
with __asan_load8, which looks wrong to me, because the library does not
provide any such entry point.

By default asan-instrumentation-with-call-threshold is INT_MAX which means that compiler will never generate __asan_load*/__asan_store* calls unless forced by the user (e.g. for Kasan).

But, in execute_sanopt force !use_calls
for (flag_sanitize & SANITIZE_USER_ADDRESS).

Do you think above limitation is not enough?

Thus, IMHO the:
   if ((flag_sanitize & SANITIZE_USER_ADDRESS) != 0
       && ((size_in_bytes & (size_in_bytes - 1)) != 0
	  || (unsigned HOST_WIDE_INT) size_in_bytes - 1 >= 16))
     return;
should be nuked from 4.9, we can do unaligned/non-{1,2,4,8,16}
accesses fine.

Right. I'd also import misalign tests.

Or were there any bugfixes needed for __asan_report_{store,load}_n
on the library side?

I don't think so.

-Y


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