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@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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to