minicore编译调试

① tiny core linux如何安装GCC编译器啊，有没有必要安装

这个应该都会自带的吧，因为有一些软件包都是源码包，是需要自己编译的。 这就是为什么编译器被称为系统软件的原因。这个很重要的。

② mcore的交叉编译环境怎么建立

建立针对arm的交叉编译开发环境为例来解说整个过程，其他的体系结构与这个相类似，只要作一些对应的改动。我的开发环境是，宿主机 i386-RedHat-7.2，目标机 arm。这个过程如下1. 下载源文件、补丁和建立编译的目录2. 建立内核头文件3. 建立二进制工具（binutils）4. 建立初始编译器（bootstrap gcc）5. 建立c库(glibc)6. 建立全套编译器（full gcc）

③ 三星galaxy core mini无法连接电脑

根据您的描述，您可按照以下操作：
1.电脑下载安装kies3驱动软件，具体kies3下载地址请您访问：
http://www.samsung.com/cn/support/usefulsoftware/KIES/JSP
2.手机关闭usb调试功能，如果使用第三方手机助手连接手机，需要开启USB调试选项，该手机为4.3系统，USB调试功能在"开发者选项中“。开发者选项为系统隐藏项目，您可按照以下方法打开此隐藏项目：
待机画面点击应用程序-点击设定-选择-”一般“标签-关于设备-连续点击内部版本号7次（可根据弹出提示预览剩余次数）-返回上层菜单即可调出开发者选项后，即可查看到USB调试选项。
3.然后手机连接电脑即可。
若使用为第三方手机助手连接手机，连接后，手机会弹出提示框是否允许USB调试。点击确定
若上述操作后仍无法连接电脑，建议：
1.检查电脑中Windows Media Player是否安装，检查电脑中Windows Media Player版本是否在11以上，若版本较低，建议下载最新版本软件。
2.更换电脑USB接口，台式机建议用主机后面的USB端口。
3.如果条件允许，更换数据线尝试一下连接
4.关闭电脑中的杀毒软件或防火墙尝试。
5.有可能跟电脑系统兼容程序有关，也可更换其他电脑尝试连接。

④ 1 linux下调试core的命令，察看堆栈状态命令

比方说，你要调试的core文件是 core.xxx，原始可执行文件是 a.exe

先用 gdb a.exe 进入 gdb，在gdb命令行下 执行

core-file /path/to/core.xxx
然后即可调试core mp文件了，比如用 bt 等

⑤ 如何编译运行minigui 3.0.1图形库

MiniGUI 提供了最简便的安装方法，只需要挂载光盘并运行光盘中根目录下的 install.sh 脚本即可。您可以通过下边的命令查看 install.sh 的帮助信息。
user$ ./install.sh --help

由帮助信息可得到安装时需要以下参数：
--adp_inst_dir ：指定库的安装路径，默认安装路径为 /usr/local/ 目录
--src_inst_dir ：指定组件及其依赖库代码解压路径，默认解压路径为主目录，比如使用的用户名为test，那么解压路径为 /home/test/ 目录
--minigui_runmode ：指定您要安装的 MiniGUI 运行模式，默认的 MiniGUI 运行模式是进程版（标准版和评估版中只有线程模式，因此无需此安装选项）
以下是安装 MiniGUI 进程版本到默认路径 /usr/local 目录下，并且将组件及其依赖库等源代码解压到 /home/test/3.0.2 路径下的示例。
user$ sudo ./install.sh --adp_inst_dir=/usr/local --src_inst_dir=/home/test/3.0.2 \ --minigui_runmode=procs

⑥ minicore芯片仪出现an error motor move with minicore怎么办

·可以自动控制组织芯片模块的X-Y轴打孔位置
·打孔器自动旋转对标本取样，自动计算取样细胞坐标，自动传送组织样本到对应位置，针对样本模块和组织芯片模块快速植入植出系统
·连接到计算机上指出模块ID选择组织类型
·取样放样打孔器同轴打孔技术，不需要打孔针校准，保证长期有效的打孔位置减少维护次数
·可以精确控制标本

⑦ 如何编译和调试android源码中platform/system/core下的代码

首先在Android源代码目录下的build目录下，有个脚本文件envsetup.sh，执行这个脚本文件后，就可以获得一些有用的工具：
USER-NAME@MACHINE-NAME:~/Android$ . ./build/envsetup.sh
注意，这是一个source命令，执行之后，就会有一些额外的命令可以使用：
- croot: Changes directory to the top of the tree.
- m: Makes from the top of the tree.
- mm: Builds all of the moles in the current directory.
- mmm: Builds all of the moles in the supplied directories.
- cgrep: Greps on all local C/C++ files.
- jgrep: Greps on all local Java files.
- resgrep: Greps on all local res/*.xml files.
- godir: Go to the directory containing a file.
这些命令的具体用法，可以在命令的后面加-help来查看，这里我们只关注mmm命令，也就是可以用它来编译指定目录的所有模块，通常这个目录只包含一个模块。

⑧ 如何调试复杂的coremp文件

调试Dump文件很简单，双击自动打开VC然后F7运行。
但是中间要注意很多事情。

1。Dump文件放在哪里

Dump文件不用非要放在你编译出来的位置，你完全可以建立一个新的文件夹来放它。

2。要恢复当时的现场

可能你要问，怎么可能，这个mp文件可是用户发给我的，我不可能去用户家里调试吧？
这个恢复现场可不是指的非要到那台机器上去，而是要把产生mp文件对应的二进制文件拿到。

但是恢复现场需要所有的二进制文件都要对应，你一定要有导致用户崩溃的那些Exe和Dll。既然是你发布的程序，Exe文件当然你会有。所以这里只考虑Dll就行了。
Dump文件中记录了所有dll文件的版本号和时间戳，所以你一定可以同过某种途径拿到它。如果你能从用户那里拿到最好，如果不方便，用户不可能用的是我们平常不常用的操作系统，所以找个有对应系统的机器一般都会有。但是记住不光是文件名称要一致，还要核对版本和时间戳，如果不同一样没有办法用。

如果客户用了某个特殊的补丁怎么办？
其实这个问题也很好解决，只要它不阻碍阅读堆栈，就不用管它，调试Dump和运行程序不一样，缺少一两个Dll没有任何问题。

如果真的需要怎么办？
那就看下面一节。

3。符号文件

符号文件现在主要是指PDB文件。

如果没有符号文件，那么调试的时候可能导致堆栈错误。
如果你丢失了这个发布里边你编译出来的那些exe和dll的PDB，那么这个损失是严重的，你重新编译出来的版本是不能使用的，乖乖的看反汇编自己猜位置吧。不过也有特殊的方法可以弥补，这里不讨论。所以一定要在发布的时候把你自己的所有PDB文件都备份起来。

⑨ 怎样用GDB调试core文件

一般这种情况都是因为数组越界访问，空指针或是野指针读写造成的。程序小的话还比较好办，对着源代码仔细检查就能解决。但是对于代码量较大的程序，里边包含N多函数调用，N多数组指针访问，这时想定位问题就不是很容易了（此时牛人依然可以通过在适当位置打printf加二分查找的方式迅速定位:P）。懒人的话还是直接GDB搞起吧。 神马是Core Dump文件偶尔就能听见某程序员同学抱怨“擦，又出Core了！”。简单来说，core mp说的是操作系统执行的一个动作，当某个进程因为一些原因意外终止（crash）的时候，操作系统会将这个进程当时的内存信息转储（mp）到磁盘上1。产生的文件就是core文件了，一般会以core.xxx形式命名。 如何产生Core Dump 发生doremp一般都是在进程收到某个信号的时候，Linux上现在大概有60多个信号，可以使用 kill -l 命令全部列出来。sagi@sagi-laptop:~$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX针对特定的信号，应用程序可以写对应的信号处理函数。如果不指定，则采取默认的处理方式, 默认处理是coremp的信号如下：3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS 5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT 我们看到SIGSEGV在其中，一般数组越界或是访问空指针都会产生这个信号。另外虽然默认是这样的，但是你也可以写自己的信号处理函数改变默认行为，更多信号相关可以看参考链接33。 上述内容只是产生coremp的必要条件，而非充分条件。要产生core文件还依赖于程序运行的shell，可以通过ulimit -a命令查看，输出内容大致如下：sagi@sagi-laptop:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 看到第一行了吧，core file size，这个值用来限制产生的core文件大小，超过这个值就不会保存了。我这里输出是0，也就是不会保存core文件，即使产生了，也保存不下来==! 要改变这个设置，可以使用ulimit -c unlimited。 OK, 现在万事具备，只缺一个能产生Core的程序了，介个对C程序员来说太容易了。#include ; #include ; int crash() { char *xxx = "crash!!"; xxx[1] = 'D'; // 写只读存储区! return 2; } int foo() { return crash(); } int main() { return foo(); } 上手调试 上边的程序编译的时候有一点需要注意，需要带上参数-g, 这样生成的可执行程序中会带上足够的调试信息。编译运行之后你就应该能看见期待已久的“Segment Fault(core mped)”或是“段错误 (核心已转储)”之类的字眼了。看看当前目录下是不是有个core或是core.xxx的文件。祭出linux下经典的调试器GDB，首先带着core文件载入程序：gdb exefile core，这里需要注意的这个core文件必须是exefile产生的，否则符号表会对不上。载入之后大概是这个样子的：sagi@sagi-laptop:~$ gdb coremp core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in crash () at coremp.c:8 8 xxx[1] = 'D'; (gdb)我们看到已经能直接定位到出core的地方了，在第8行写了一个只读的内存区域导致触发Segment Fault信号。在载入core的时候有个小技巧，如果你事先不知道这个core文件是由哪个程序产生的，你可以先随便找个代替一下，比如/usr/bin/w就是不错的选择。比如我们采用这种方法载入上边产生的core，gdb会有类似的输出：sagi@sagi-laptop:~$ gdb /usr/bin/w core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in ? () (gdb)可以看到GDB已经提示你了，这个core是由哪个程序产生的。 GDB 常用操作 上边的程序比较简单，不需要另外的操作就能直接找到问题所在。现实却不是这样的，常常需要进行单步跟踪，设置断点之类的操作才能顺利定位问题。下边列出了GDB一些常用的操作。 启动程序：run
设置断点：b 行号|函数名
删除断点：delete 断点编号
禁用断点：disable 断点编号
启用断点：enable 断点编号
单步跟踪：next 也可以简写 n
单步跟踪：step 也可以简写 s
打印变量：print 变量名字
设置变量：set var=value
查看变量类型：ptype var
顺序执行到结束：cont
顺序执行到某一行： util lineno打印堆栈信息：bt

⑩ 如何调试编译时注解处理器AnnotationProcessor

ALU内含电路系统，易于输出端完成简单的普通运算和逻辑运算（比如加法和位元运算）。如果加法运算产生一个对该CPU处理而言过大的结果，在标志暂存器里可能会设置运算溢出（Arithmetic Overflow）标志。