File: sarp.c

package info (click to toggle)
valgrind 1%3A3.24.0-3
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 176,332 kB
  • sloc: ansic: 795,029; exp: 26,134; xml: 23,472; asm: 14,393; cpp: 9,397; makefile: 7,464; sh: 6,122; perl: 5,446; python: 1,498; javascript: 981; awk: 166; csh: 1
file content (47 lines) | stat: -rw-r--r-- 1,345 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// This artificial program allocates and deallocates a lot of large objects
// on the stack.  It is a stress test for Memcheck's set_address_range_perms
// (sarp) function.  Pretty much all Valgrind versions up to 3.1.X do very
// badly on it, ie. a slowdown of at least 100x.
//
// It is representative of tsim_arch, the simulator for the University of
// Texas's TRIPS processor, whose performance under Valgrind is dominated by
// the handling of one frequently-called function that allocates 8348 bytes
// on the stack.

#include <assert.h>
#include <time.h>

#define REPS   1000*1000*10

__attribute__((noinline))
int f(int i)
{
   // This nonsense is just to ensure that the compiler does not optimise
   // away the stack allocation.
   char big_array[500];
   big_array[  0] = 12;
   big_array[ 23] = 34;
   big_array[256] = 56;
   big_array[434] = 78;
   assert( 480 == (&big_array[490] - &big_array[10]) );
   return big_array[i];
}

int main(void)
{
   int i, sum = 0;

   struct timespec req __attribute__((unused));
   req.tv_sec  = 0;
   req.tv_nsec = 100*1000*1000;   // 0.1s

   // Pause for a bit so that the native run-time is not 0.00, which leads
   // to ridiculous slow-down figures.
   //nanosleep(&req, NULL);
   
   for (i = 0; i < REPS; i++) {
      sum += f(i & 0xff);
   }
   return ( sum == 0xdeadbeef ? 1 : 0 );
}