[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp requested changes to this revision.
dkrupp added a comment.
This revision now requires changes to proceed.

Please fix the incompatibility between analyze-build and lib/CrossTU in the format of externalFnMap.txt mappfing file.



================
Comment at: tools/scan-build-py/libscanbuild/analyze.py:535
+        ast_path = os.path.join("ast", triple_arch, path + ".ast")
+        func_ast_list.append(mangled_name + "@" + triple_arch + " " + ast_path)
+    return func_ast_list
----------------
There is a incompatibility between this scan-build (analyze-build actually) implementation and new lib/CrossTU library.

CrossTranslationUnitContext::loadExternalAST(
    StringRef LookupName, StringRef CrossTUDir, StringRef IndexName)

expects the externalFnMap.txt to be in
"functionName astFilename" format.
however currently we generate here
"functionName at arch astFilename" lines.

One possible fix could be to 
create one externalFnMap.txt indexes per arch
<collect-dir>/ast/x86_64/externalFnMap.txt
<collect-dir>/ast/ppc64/externalFnMap.txt
etc.
and call clang analyze with the architecture specific map directory: 
e.g. ctu-dir=<collect-dir>/ast/x86_64

This would then work if the "to-be-analyzed" source-code is cross-compiled into multiple architectures.

Would be useful to add a test-case too to check if the map file and ctu-dir content generated by analyze-build is compatible.


================
Comment at: tools/scan-build-py/libscanbuild/analyze.py:585
+        + [opts['file']]
+    triple_arch = get_triple_arch(cmd, cwd)
+    generate_ast(triple_arch)
----------------
Maybe we could use the full target-triple for distinguishing the AST binaries, not only the architecture part. The sys part for example is probably important too and a "win32" AST may not be compatible with a "linux" AST.


https://reviews.llvm.org/D30691