clang/README.md

   1 Contains a Clang extension which generates MC2 calls based on calls already in the code.
   2
   3 * To compile this code, you need to modify the build paths in
   4 the Makefile; point them at your LLVM build. Then running 'make' should work.
   5
   6 * To run the code, you can specify the include directories explicitly:
   7
   8 build/add_mc2_annotations ../test/userprog_unannotated.c -- -I/usr/include -I../../llvm/tools/clang/lib/Headers -I../include
   9
  10 I can't figure out how to make Clang's compilation database work for me.
  11
  12 * Currently, the tool will fail if it tries to rewrite any code that uses macros.
  13 One example of a macro is "bool".
  14
  15 The following StackOverflow link explains how to overcome that problem.
  16
  17 http://stackoverflow.com/questions/24062989/clang-fails-replacing-a-statement-if-it-contains-a-macro
  18
  19 It's on the TODO list.
  20
  21 * The tool won't deal properly with a malloc hidden behind a cast,
  22 e.g. (struct node *) malloc(sizeof(struct node *)). You don't need to
  23 cast the malloc. Ignoring the cast is on the TODO list, but not done yet.
  24
  25 * Naked loads aren't allowed, e.g. Load_32(&x) without y = Load....
  26
  27 This is especially relevant in the context of a loop, e.g. while (Load_32(&x)).
  28
  29 >    for (int i = 0; i < PROBLEMSIZE; i++)
  30 >        r1 = seqlock_read();
  31
  32 * for loops with a non-CompoundStmt body can generate wrong code
  33 * if you throw away the return value (just "seqlock_read()"), then the rewriter won't work right either
  34
  35
  36 linuxlock, linuxrwlock.
  37 * I changed the global 'mylock' variable so that it's allocated on the heap, not
  38 as a global variable.
  39 * Should I look into the fact that linuxlock now generates nextOpStoreOffset rather than nextOpStore
  40 as in the golden master? That is probably actually correct.
  41
  42 -----
  43
  44 1. variables of union type which are allocated as global variable and then nextOpStoreOffset'd cause a problem
  45 2. boolean types are handled as macros and so there's no source position
  46 3. if statements with conds like "if (write_trylock(mylock))" don't work.
  47 4. malloc on vardecl (e.g. struct node * node_ptr = (struct node *)malloc) don't always get mc2_function generated for them [ms-queue-simple]
  48 5. nextOpLoadOffset not generated in following case:
  49
  50                MCID _fn1; struct node ** tail_ptr_next= & tail->next;
  51                _fn1 = MC2_function_id(2, 1, sizeof (tail_ptr_next), (uint64_t)tail_ptr_next, _mtail);
  52
  53                MCID _mnext; _mnext=MC2_nextOpLoadOffset(_fn1, MC2_OFFSET(struct node *, next)); struct node * next = (struct node *) load_64(tail_ptr_next);
  54
  55 currently we generate nextOpLoad.