[llvmlinux] [GSoC: Static analysis] Report 1 + PATCH

Jan-Simon Möller dl9pf at gmx.de
Fri Jun 28 14:58:15 UTC 2013


Probably a good question for llvmdev ML or a bugreport.

Attached is an strace which also shows this behaviour (line 4118 vs. 41105).


-- 

Dipl.-Ing.
Jan-Simon Möller

jansimon.moeller at gmx.de
On Friday 28 June 2013 16:08:55 Eduard Bachmakov wrote:
> Thanks everyone!
> 
> On Thu, Jun 27, 2013 at 2:30 PM, salvatore benedetto <
> 
> salvatore.benedetto at gmail.com> wrote:
> > I don't know if it can be of any help, but when I had to figure out the
> > correct
> > triple and flags for cross-compiling I had to dig down into the code since
> > it is a real mess and not documented.
> > 
> > This is where the conversion takes place (yes, there is duplicated code in
> > both
> > files for ARM targets)
> > 
> > https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains.cpp
> > https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChain.cpp
> > 
> > the -triple argument in the cc1 stage is influeced by the -target option
> > of the previous stage.
> 
> https://github.com/llvm-mirror/clang/blob/master/lib/Driver/Tools.cpp#L1922
> 
> This is a good starting point! So, going off of Tools.cpp, how is
> -target-cpu set?
> 
> void ClangAs::AddARMTargetArgs(const ArgList &Args, ArgStringList &CmdArgs)
> const
> calls
>   static std::string getARMTargetCPU(const ArgList &Args, const
> llvm::Triple &Triple)
>   where StringRef MArch is set to the -march= value or Triple.getArchName()
> if absent (triple = getToolChain().getTriple()). Before returning "armv7a"
> becomes "cortex-a8" which is returned
> 
> So, in other words, there shouldn't be a problem is -march is defined right
> and should have prededence over the triple.
> 
> How does ccc-analyzer construct the calls to clang itself?
> First the compile happens with unmodified arguments. Then stuff is set up
> for the analysis run. The call is
> my $AnalysisArgs = GetCCArgs("--analyze", \@Args); where GetCCArgs is
> basically reading the output of "clang -### -fsyntax-only --analyze
> <somewhat modified original args>".
> 
> THIS is important. Where does it go wrong then? A few debugging statements
> show that
> 
> '/home/e/llvmlinux/toolchain/clang/install/bin/clang-3.4' '-###' ''
> '-fsyntax-only' '-x' 'c' '-nostdinc' '-isystem'
> '/home/e/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.4/include'
> '-I/home/e/llvmlinux/targets/vexpress/src/linux/arch/arm/include'
> '-Iarch/arm/include/generated' '-Iinclude'
> '-I/home/e/llvmlinux/targets/vexpress/src/linux/arch/arm/include/uapi'
> '-Iarch/arm/include/generated/uapi'
> '-I/home/e/llvmlinux/targets/vexpress/src/linux/include/uapi'
> '-Iinclude/generated/uapi' '-include'
> '/home/e/llvmlinux/targets/vexpress/src/linux/include/linux/kconfig.h'
> '-D__KERNEL__' '-mlittle-endian' '-Wno-trigraphs' '-Wno-format-security'
> '-fno-builtin' '-Wno-asm-operand-widths' '-mno-warn-deprecated'
> '-D__LINUX_ARM_ARCH__=7' '-march=armv7-a' '-msoft-float'
> '-Wno-unused-variable' '-Wno-format-invalid-specifier'
> '-Wno-tautological-compare' '-Wno-pointer-sign'
> '-DKBUILD_BASENAME=KBUILD_STR(bounds)'
> '-DKBUILD_MODNAME=KBUILD_STR(bounds)' 'kernel/bounds.c'
> 
> becomes
> 
> clang version 3.4
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> clang-3.4: warning: argument unused during compilation: '-mlittle-endian'
> clang-3.4: warning: argument unused during compilation:
> '-mno-warn-deprecated'
>  "/home/e/llvmlinux/toolchain/clang/install/bin/clang-3.4" "-cc1" "-triple"
> "x86_64-unknown-linux-gnu" "-fsyntax-only" "-disable-free"
> "-disable-llvm-verifier" "-main-file-name" "bounds.c" "-mrelocation-model"
> "static" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose"
> "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array"
> "-no-implicit-float" "-target-cpu" "armv7-a" "-nostdsysteminc"
> "-nobuiltininc" "-resource-dir"
> "/home/e/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.4" "-isystem"
> "/home/e/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.4/include"
> "-include"
> "/home/e/llvmlinux/targets/vexpress/src/linux/include/linux/kconfig.h" "-D"
> "__KERNEL__" "-D" "__LINUX_ARM_ARCH__=7" "-D"
> "KBUILD_BASENAME=KBUILD_STR(bounds)" "-D"
> "KBUILD_MODNAME=KBUILD_STR(bounds)" "-I"
> "/home/e/llvmlinux/targets/vexpress/src/linux/arch/arm/include" "-I"
> "arch/arm/include/generated" "-I" "include" "-I"
> "/home/e/llvmlinux/targets/vexpress/src/linux/arch/arm/include/uapi" "-I"
> "arch/arm/include/generated/uapi" "-I"
> "/home/e/llvmlinux/targets/vexpress/src/linux/include/uapi" "-I"
> "include/generated/uapi" "-Wno-trigraphs" "-Wno-format-security"
> "-Wno-asm-operand-widths" "-Wno-unused-variable"
> "-Wno-format-invalid-specifier" "-Wno-tautological-compare"
> "-Wno-pointer-sign" "-fdebug-compilation-dir"
> "/home/e/llvmlinux/targets/vexpress/src/linux" "-ferror-limit" "19"
> "-fmessage-length" "239" "-mstackrealign" "-fno-builtin"
> "-fobjc-runtime=gcc" "-fobjc-default-synthesize-properties"
> "-fdiagnostics-show-option" "-fcolor-diagnostics" "-backend-option"
> "-vectorize-loops" "-x" "c" "kernel/bounds.c"
> 
> So there it is! The question is what now ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_ccc-analyzer.tar.bz2
Type: application/x-bzip-compressed-tar
Size: 375085 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130628/695303e2/attachment-0001.bin>


More information about the LLVMLinux mailing list