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
