[compiler-rt] r226202 - [asan] Loosen test for upcoming ppc64 change

[Hal Finkel]

Author: hfinkel
Date: Thu Jan 15 14:48:38 2015
New Revision: 226202

URL: http://llvm.org/viewvc/llvm-project?rev=226202&view=rev
Log:
[asan] Loosen test for upcoming ppc64 change

This test casts 0x4 to a function pointer and calls it. Unfortunately, the
faulting address may not exactly be 0x4 on PPC64 ELFv1 systems. The LLVM PPC
backend used to always generate the loads "in order", so we'd fault at 0x4
anyway. However, at upcoming change to loosen that ordering, and we'll pick a
different order on some targets. As a result, as explained in the comment, we
need to allow for certain nearby addresses as well.

Modified:
    compiler-rt/trunk/test/asan/TestCases/zero_page_pc.cc

Modified: compiler-rt/trunk/test/asan/TestCases/zero_page_pc.cc
URL: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/test/asan/TestCases/zero_page_pc.cc?rev=226202&r1=226201&r2=226202&view=diff
==============================================================================
--- compiler-rt/trunk/test/asan/TestCases/zero_page_pc.cc (original)
+++ compiler-rt/trunk/test/asan/TestCases/zero_page_pc.cc Thu Jan 15 14:48:38 2015
@@ -6,7 +6,11 @@ int main() {
   void_f *func = (void_f *)0x4;
   func();
   // x86 reports the SEGV with both address=4 and pc=4.
-  // PowerPC64 reports it with address=4 but pc still in main().
-  // CHECK: {{AddressSanitizer: SEGV.*(address|pc) 0x0*4}}
+  // On PowerPC64 ELFv1, the pointer is taken to be a function-descriptor
+  // pointer out of which three 64-bit quantities are read. This will SEGV, but
+  // the compiler is free to choose the order. As a result, the address is
+  // either 0x4, 0xc or 0x14. The pc is still in main() because it has not
+  // actually made the call when the faulting access occurs.
+  // CHECK: {{AddressSanitizer: SEGV.*(address|pc) 0x0*[4c]}}
   return 0;
 }