TySan doesn't catch strict-aliasing violation when using struct initializers

[fhahn]

The initial version of TySan (#76261) doesn't properly report the first strict aliasing violation in the test case below

#include <stdio.h>

__attribute__((noinline))
void print(char**v) {
    printf("%s\n", v[0]);
}

int main() {
  char *values[2] = { "value", 0};
  void **curr = ((void *) values);
  int count;
  for (count = 0; curr && curr[count]; count++);

  values[0] = "test";
  print(values);
  return count;
}

Produces the output below with TySan. It looks like it is missing setting the initial type of values and the first reported violation is values[0] = "test";, while it should already report the read of void * for curr[count] from memory with char *.

> bin/clang -fsanitize=type test.c -O1  -g -isysroot $MACOS_SYSROOT
>  ./a.out
==81689==ERROR: TypeSanitizer: type-aliasing-violation on address 0x00016b16b1c0 (pc 0x000104c97dac bp 0x00016b16b1b0 sp 0x00016b16a940 tid 18058865)
WRITE of size 8 at 0x00016b16b1c0 with type p1 omnipotent char accesses an existing object of type p1 void
    #0 0x000104c97da8 in main test.c:14

==81689==ERROR: TypeSanitizer: type-aliasing-violation on address 0x00016b16b1c0 (pc 0x000104c97a68 bp 0x00016b16b180 sp 0x00016b16a910 tid 18058865)
READ of size 8 at 0x00016b16b1c0 with type p1 omnipotent char accesses an existing object of type p1 void
    #0 0x000104c97a64 in print test.c:5

test

[fhahn]

I think this is the underlying issue of why TySan doesn't detect the strict-aliasing violation in #119099

[gbMattN]

Hi @fhahn, I could look into fixing this if you aren't already?

[fhahn]

@gbMattN that would be great thanks. I've not looked into it yet, but IIRC it looks like Clang doesn't emit TBAA metadata for the initializer

[gbMattN]

The following values exist in the IR pre-tysan pass

@.str.1 = private unnamed_addr constant [6 x i8] c"value\00", align 1
@__const.main.values = private unnamed_addr constant [2 x ptr] [ptr @.str.1, ptr null], align 16

char *values[2] = { "value", 0}; is internally implimented as a memcpy from @__const.main.values to values. We instrument this with __tysan_instrument_mem_inst, which copies the shadow memory of the source to the shadow memory of the target. But the shadow memory for @__const.main.values or @.str.a was never set.

Despite being global values, as they are not global variables, the instrumentGlobals function doesn't find them. You are also correct about them not having TBAA metadata, which will make this a bit tricky! Their IR definitions do include type information though.
I'll look more into a way to get this to work. Hopefully the solution will help with future TBAA related issues TySan has.

[gbMattN]

The approach I've gone with is to record a map of llvm::Type* to GlobalVariable*, being the type of the instruction and the TD generated from its TBAA metadata respectively. Then, for these global values with no TBAA metadata, you can assign it a TD by looking at this mapping.

The intuition behind this idea is that if this global value is every used correctly, that usage would have the correct TBAA, and thus create the correct TD. Therefore for any TBAA-data-less global value you use, the TD would exist. I have a branch on my fork where I implement this and it acts correctly in the test case above. This approach could be extended for any other issues that arise due to TBAA limitations.

@fhahn, The code has some hacks in it currently which I would want to refactor before raising it as a pull request, but I'd like to check if this approach sounds good to you first.