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