objdump命令是Linux下的反汇编目标文件或者可执行文件的命令，它以一种可阅读的格式让你更多地了解二进制文件可能带有的附加信息。
在我们跑harmony的开源用例的时候总是会遇到一些用例会crash，首先我们要分析造成用例crash的原因是否为用户态异常造成的。当是用户态异常造成的用例crash的情况，可以依照以下的步骤去分析原因。
1.使用命令file去查看Bin文件是否可以stripped
$ file ActsProcessApiTest.bin
ActsProcessApiTest.bin: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-arm.so.1, not stripped
2.生成符号文件
$ ~/llvm/bin/llvm-objdump -d ActsProcessApiTest.bin > ActsProcessApiTest.asm
objdump是gcc工具链中的反汇编工具，所以我们可以直接 obhdum -d elf文件 > asm.文件命令去反编译出二进制的文件。但是，在该项目中我们使用的是L1版本的，在L1中我们使用的是clang，所以在这个命令之前加上llvm的安装路径。
3.实例介绍
可以看到这是一个ActsProcessApiTest.bin的里面用例crash了，当Crash的用例会有异常调用栈信息，关注里面的ulr和pc的信息，可以看见这个造成crash的情况是因为libc.so这个文件是有问题的。
所以我们去反编译这个文件去查找原因，该文件是在out/hispark_taurus/ipcamera_hispark_taurus/libs/libc.so目录的，所以我们进入该目录去反编译这个文件。
可以看到已经城生成了asm.asm
4.根据pc或者ulr提供的信息去定位清理。
再跟这里的ulr和pc的二进制码去asm文件里面查找看到底是那一块的函数是有问题的。分别在asm文件里找到对应的码值。
例如：pc的9beec 在asm里面所对应的信息为：
再向上查找可以看到对应的函数接口：
可以看到是对应的pthread_barrier_wait这个函数接口造成了用户态异常。
5.我们在去第三方库里看这个函数的实现，看具体的哪一步操作导致了这个问题。
首先找到实现这个函数接口的文件：
可以看见这个函数接口的实现是在src/thread的目录下的。再接着在asm文件里面看对应的二进制操作在这个.c文件里面寻找相同的操作，找到了 应该就是这个段代码所造成的crash情况。
