e67f32aa99
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. llvm-svn: 226202
17 lines
702 B
C++
17 lines
702 B
C++
// Check that ASan correctly detects SEGV on the zero page.
|
|
// RUN: %clangxx_asan %s -o %t && not %run %t 2>&1 | FileCheck %s
|
|
|
|
typedef void void_f();
|
|
int main() {
|
|
void_f *func = (void_f *)0x4;
|
|
func();
|
|
// x86 reports the SEGV with both address=4 and pc=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;
|
|
}
|