Swift Taint Tests

[janniclas]

This PR contains a first set of Swift tests for the IFDS Taint Analysis.
Also code style changes were applied to existing Swift tests.

We currently can't correctly handle the CommandLine arguments and exceptions and the corresponding tests are therefore disabled.

To fix the exception handling we most likely need to update the handling of the load instruction similarly to the workaround we implemented for the LCA.

Code pattern causing the problem:

  %._value1 = getelementptr inbounds %TSi, %TSi* %0, i32 0, i32 0, !dbg !120
  %14 = load i64, i64* %._value1, align 8, !dbg !120

This will be addressed in a later PR.

[janniclas]

@fabianbs96 I just changed the Taint Analysis' handling of the Store instruction to reuse our workaround from the LCA.
This kinda helps with the exception handling, however I'm not 100% sure if this is the best solution. I would actually expect that maybe the alias information handled this use case.
The previously problematic sequence of IR statements is shown below (minimized version from taint_exception_05.swift).

12:                                               ; preds = %10, %15

// here we load the value from %0 which was tainted previously and let it flow into sink
  %._value2 = getelementptr inbounds %TSi, %TSi* %0, i32 0, i32 0, !dbg !118
  %13 = load i64, i64* %._value2, align 8, !dbg !118
  call swiftcc void @sink(i64 %13), !dbg !119
  ret void, !dbg !120

15:                                               ; preds = %entry
  %16 = phi %swift.error* [ %8, %entry ], !dbg !113
  store %swift.error* null, %swift.error** %swifterror, align 8, !dbg !116
  %17 = bitcast %T18taint_exception_051SV* %2 to i8*, !dbg !116
  %18 = bitcast %swift.error* %16 to %swift.refcounted*, !dbg !121
  %19 = call %swift.refcounted* @swift_retain(%swift.refcounted* returned %18) #2, !dbg !121
  store %swift.error* %16, %swift.error** %error.debug, align 8, !dbg !122

// Source tainting %0 through store instruction  (this is addressed by our store workaround)
  %20 = call swiftcc i64 @source(), !dbg !123
  %._value1 = getelementptr inbounds %TSi, %TSi* %0, i32 0, i32 0, !dbg !125
  store i64 %20, i64* %._value1, align 8, !dbg !125


  call void bitcast (void (%swift.refcounted*)* @swift_release to void (%swift.error*)*)(%swift.error* %16) #2, !dbg !108
  call void bitcast (void (%swift.refcounted*)* @swift_release to void (%swift.error*)*)(%swift.error* %16) #2, !dbg !108
  br label %12, !dbg !108
}

The analysis now reports the following leak. I would actually expect it to report %0, however %_value2 does make sense if I look at the IR, what do you think?

\
----- Found the following leaks -----
At instruction
IR  : call swiftcc void @sink(i64 %13), !dbg !215, !psr.id !216 | ID: 93


Leak(s):
IR  : %._value2 = getelementptr inbounds %TSi, %TSi* %0, i32 0, i32 0, !dbg !212, !psr.id !213 | ID: 91

[fabianbs96]

Hi @janniclas, thanks for pointing this out. You are right, the store should actually habe handled by the alias information. However, it seems that we are only generating aliases when calling a source-function with output-parameters and considering them for creating leak-sets. This should probably be fixed in the future; for now, your workaround makes sense.

Regarding the leak-reporting: We have that lines Leaks[CallSite].insert(Source); for sink statements. The source that flows into the sink is %13 in this case. In the emitTextReport we are explicitly checking for load instructions (%13 is a load) and reporting the load's pointer-operand instead. This may or may not be intuitive. You can change it if you like.

Btw. I enabled compiling the swift tests on my system and it seems for them the incremental build does not work properly, i.e. every time when I rebuild phasar (incrementally) it rebuilds all swift tests. Can you fix it?

[janniclas]

I extended this PR with fixes to finally support PhASAR on Macs with the new Apple Silicon.
I also addressed the issue regarding the rebuilding of the swift tests @fabianbs96 mentioned. please check on your system if this behavior is also resolved for you

[fabianbs96]

Do these flags have to be env variables? Or can they also be supplied to cmake directly?

[janniclas]

What we could do is define it as a default variable in cmake and users could change it with a cmake flag like
-DPathToLLVM=/my/custom/llvm/install/llvm@14
I think this could make sense.

[fabianbs96]

We should probably add a comment to describe why we exclude pmr on apple.

Btw, are the feature-test macros __cpp_lib_memory_resource and __cpp_lib_polymorphic_allocator defined on apple?

[fabianbs96]

We should also generate insert from Insert->getAggregateOperand()