使用clion阅读任意交叉编译软件的代码

clion是linux下比较强大的C/C++ IDE，通过扩展也可以支持很多其他语言，例如shell,lua, perl, python,rust。唯一缺点是收费，但是相对它给我带来的便利，这点费用不算什么。我一般用来开发C/C++/项目，它支持3种方式解析工程源码，分别是

• Makefile
• CMake
• 编译数据库

像代码的高亮，跳转，补全，都依赖对源码的解析，其实CMake和Makefile应该是一回事，CMake最终也会生成Makefile。首先通过make分析出工程里面用到哪些源文件，然后通过内置语法分析器解析得到符号表等信息，从而实现高亮，补全等。

当你的工程是针对你开发的PC时，这些都没问题，但是如果是交叉编译时，便会由于无法通过make来获取依赖的源文件，导致接下来的语法分析也无法进行。例如基于openwrt，buildroot开发时，或者编译uboot,kernel。因为这些构建框架都有自己特定的一些环境变量，编译脚本什么的，导致clion这种IDE无法简单的通过指定工具链来执行make,来分析依赖的源文件。于是编译数据库这种方式就派上了用场。cmake可以直接生成编译数据库，通过cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1，但是嵌入式开发里面用的一些库，工具可能是基于比较古老的版本，仅支持automake, makefile等。此时需要借助另一个工具bear，ubuntu20.04上直接apt安装即可，或者源码编译。bear的用法十分的简单

bear 编译命令
#例如，builrdroot中编译某个软件
bear make xl2tpd-{dirclean,build}
#或者,openwrt中
bear make package/xl2tpd/{clean,prepare,compile}

它的工作原理好像是创建子进程执行编译命令，然后监听工具链的gcc的调用，类似strace分析gcc的调用，知道gcc执行时，参数是怎么样的，open等系统调用又是怎么样的。最终生成编译数据库文件，其实就是个json文件。这个文件里面对每个gcc处理过的文件作了记录，包括3个值:

• gcc的参数
• 源文件名称
• 源文件目录

{   
        "arguments": [
            "/home/a/workspace/exc-m620d/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.16_eabi/bin/arm-openwrt-linux-muslgnueabi-gcc",
            "-c",
            "-Os",
            "-pipe",
            "-mcpu=cortex-a7",
            "-mfpu=neon-vfpv4",
            "-fno-caller-saves",
            "-fno-plt",
            "-fhonour-copts",
            "-Wno-error=unused-but-set-variable",
            "-Wno-error=unused-result",
            "-mfloat-abi=hard",
            "-iremap/home/a/workspace/exc-m620d/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/xl2tpd-devel-20151125:xl2tpd-devel-20151125",
            "-Wformat",
            "-Werror=format-security",
            "-fstack-protector",
            "-D_FORTIFY_SOURCE=1",
            "-I/home/a/workspace/exc-m620d/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/usr/include",
            "-I/home/a/workspace/exc-m620d/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/include",
            "-I/home/a/workspace/exc-m620d/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.16_eabi/usr/include",
            "-I/home/a/workspace/exc-m620d/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.16_eabi/include/fortify",
            "-I/home/a/workspace/exc-m620d/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.16_eabi/include",
            "-DDEBUG_PPPD",
            "-DTRUST_PPPD_TO_DIE",
            "-fno-builtin",
            "-Wall",
            "-DSANITY",
            "-DLINUX",
            "-I./linux/include/",
            "-DUSE_KERNEL",
            "-DIP_ALLOCATION",
            "-o",
            "call.o",
            "call.c"
        ],
        "directory": "/home/a/workspace/exc-m620d/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/xl2tpd-devel-20151125",
        "file": "call.c"
    }

然后语法分析器就知道分析谁了。这样就可以愉快的使用clion阅读编辑跑在ARM上的代码了。不过有个地方需要注意，如果你的交叉编译工具链是通过export到环境变量的方式来执行的，那么编译数据库的的arguments的第一项，gcc就不会是一个绝对路径，导致clion解析异常，这时只要全局替换这个编译数据库文件里面的xxx-gcc为绝对路径即可。其实我认为这个应该是bear需要改进的一个地方，bear在填这个工具链的gcc时，通过realpath就知道工具链的绝对路径。