方法一：将coredump文件放到服务器，再用toolchain的gdb查看
1.打开core功能，并设置生成的core文件的路径和文件名格式（都是临时修改，重启不会保存）
ulimit -c unlimited
echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
2.生成core文件
做完第一步后，重新拉起待监测的进程，使其crash
core-myClient-11415-1635469554
3.将生成的core文件导入到服务器上
如果是ftp传输，注意切换到binary传输模式，否则会在后面出现gdb不认识core文件
4.找到toolchain里的gdb,并读取nostrip的可执行档
./msdk-linux-gdb ~ /romfs_nostrip/bin/ myClient
5.读取刚刚生成的core file,目前这个是 strip的可执行档生成的
(gdb) core-file ~/core- myClient -11415-1635469554
结果如下
Core was generated by `/bin/myClient.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x004a2c78 in set_ParameterValue (name=<error reading variable: Cannot access memory at address 0x3fec00>,
type=<error reading variable: Cannot access memory at address 0x3fec04>,
value=<error reading variable: Cannot access memory at address 0x3fec08>) at parameter_api.c:1926
1926 test_return = entity->info->op->setvalue(name, entity, type, value);
这样就可以定位到程序哪里出问题了。
方法二：借鉴客户的方法，直接编译user gdb，并放到板子当中运行
1.下载gdb 7.12 source code，并用我们的toolchain编译生成可执行档
2.将unstrip的myClient下载到板子中，修改为可执行并重新运行，等待crash出现，出现core dump file
3.运行./gdb myClient -c core- myClient -11329-1635473088
目前这个方案只是理论上行的通，实践上存在一个问题，gdb虽然可以正常起来运行，不过加入core file的时候会出现gdb crash，
看warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
应该是gdb运行依赖于libthread_db，而我们现在没有，或者版本不匹配
所以我们现在调试多线程的进程是不可以的
