1. keil编译问题 用的是4.0版本，每次编译都会出来下面提示是怎么回事
两个警告而已，警告不要紧，没有错误就能运行。
2. 最新版coreDRAW的下载地址
CorelDRAW X4 真正官方简体中文版（iso镜像） CorelDRAW X4? Graphics Suite X4套件包括：矢量图形创建、版面设计程序CorelDRAW? X4，专业图像编辑应用程序Corel PHOTO-PAINT? X4，专业位图转换矢量文件程序Corel?PowerTRACE ? X4，一键式屏幕捕捉程序Corel CAPTURE ? X4，CorelDRAW ?手册，培训视频，10,000多张高质量剪贴画和数码图像素材。 新版本包含50多项新功能和显着增强的功能，能够加快创新过程、简化项目管理和优化图形设计工作流。另外熟悉CorelDRAW的用户在新版本的包装以及界面上有看到了熟悉了热气球图标，再次唤起了人们对这款图形设计软件的很多回忆和美好情感。作为图形设计市场上主导性的软件产品，此次CorelDRAW X4?的推出无疑再次强化了其在这个领域简单高效、与生产紧密结合的优势。 下载地址 http://www.rsdown.cn/downinfo/9708.html 补充： CorelDraw12入门与实例 绿色特别版 CorelDraw12入门与实例--本人制作的 电子书 教程.供大家下载，慢慢研究学习。 下载地址 http://www.rsdown.cn/downinfo/1044.html CorelDraw12 入门与实例 [图文教程 菜鸟先飞系列教材] 这段时间想学一下coreldraw,上网找了一下资料，发觉并不多，且多是一页页打开看的，麻烦ing,为了方便学习，收集了一下，做成E-book形式，供大家下载，慢慢研究学习。 下载地址 http://www.rsdown.cn/downinfo/5376.html 补充： CorelDRAW X4 真 正官 方简体中文版（iso镜像） 是最新版的 CorelDRAW
3. keil 51中编译显示address space overlow怎么解决
地址空间溢出了，一般是RAM不够的表现。
因为不知道你程序的具体情况，所以我这里就说几个常见现象：
1、MCU的规格不够，象AT89S51是128RAM，52是256RAM，但这其中还包括了特殊寄存器，51实际也就能用80字节，这80个还要包括堆栈，所以写嵌入式程序，RAM使用一定要精打细算。
2、能用局部变量就不定义全局的，能用位变量的就不用字节变量。
3、如果有外部RAM，就尽量把对速度要求不高的变量定义在里面，但也要注意不超过其限量。
4、不用的函数就注释掉，如果实在不想注释，就象这样，也可以减少RAM的使用：
i=0;
if(i==1)
{
...
xxx();//从不调用的函数
...
}
5、尽量减少函数调用的级数
6、在项目的OPTION－》target中，memory model，根据具体硬件做选择。
4. 安装Core修改不了物理地址是什么情况
物理地址就是MAC地址，全世界的NIC都是唯一的MAC地址，是不能修改的。
所谓的修改是指通过软件修改，让网络内的所有电脑认为你的MAC地址是你修改后的地址。有些捆绑了MAC的网络，当你更换了网卡的时候，如果不想到网络提供部门申请更改捆绑，那你就可以通过第三方软件进行修改。
在计算机科学中，物理地址（英语：physicaladdress），也叫实地址（realaddress）、二进制地址（binaryaddress），它是在地址总线上，以电子形式存在的，使得数据总线可以访问主存的某个特定存储单元的内存地址。
5. 如何调试php的Core之获取基本信息
首先, 让生成一个供举例子的Core文件: <?phpfunction recurse($num) { recurse(++$num);} recurse(0); 运行这个PHP文件: $ php test.phpSegmentation fault (core mped) 这个PHP因为无线递归, 会导致爆栈, 从而造成 segment fault而在PHP的当前工作目录产生Coremp文件(如果你的系统没有产生Coremp文件, 那请查询ulimit的相关设置). 好, 现在, 让删除掉这个test.php, 忘掉上面的代码, 我们现在仅有的是这个Core文件, 任务是, 找出这个Core产生的原因, 以及发生时候的状态. 首先, 让用gdb打开这个core文件: $ gdb php -c core.31656 会看到很多的信息, 首先让我们注意这段: Core was generated by `php test.php'.Program terminated with signal 11, Segmentation fault. 他告诉我们Core发生的原因:”Segmentation fault”. 一般来说, 这种Core是最常见的, 解引用空指针, double free, 以及爆栈等等, 都会触发SIGSEGV, 继而默认的产生Coremp. 现在让看看Core发生时刻的堆栈: #0 execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:5353 memset(EX(CVs), 0, sizeof(zval**) * op_array->last_var);(gdb) bt#0 execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:53#1 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400210) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234#2 0x00000000006e9f61 in execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:92#3 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400440) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234#4 0x00000000006e9f61 in execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:92#5 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400670) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234..... 不停的按回车, 可以看到堆栈很深, 不停的是zend_do_fcall_common_helper_SPEC和execute的重复, 那么这基本就能断定是因为产生了无穷大的递归(不能一定说是无穷递归, 比如之前文章中介绍深悉正则(pcre)最大回溯/递归限制). 从而造成爆栈产生的Core. Ok, 那么现在让看看, Core发生在PHP的什么函数中, 在PHP中, 对于FCALL_* Opcode的handler来说, execute_data代表了当前函数调用的一个State, 这个State中包含了信息: (gdb)f 1#1 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400210) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234234 zend_execute(EG(active_op_array) TSRMLS_CC);(gdb) p execute_data->function_state.function->common->function_name$3 = 0x2a95b65a78 "recurse"(gdb) p execute_data->function_state.function->op_array->filename$4 = 0x2a95b632a0 "/home/laruence/test.php"(gdb) p execute_data->function_state.function->op_array->line_start$5 = 2 现在我们得到, 在调用的PHP函数是recurse, 这个函数定义在/home/laruence/test.php的第二行 经过重复验证几个frame, 可以看出, 一直是在重复调用这个PHP函数. 要注意的是, 为了介绍查看执行信息的原理, 我才采用原生的gdb的print来查看, 其实我们还可以使用PHP源代码中提供的.gdbinit(gdb命令编写脚本), 来简单的获取到上面的信息: (gdb) source /home/laruence/package/php-5.2.14/.gdbinit(gdb) zbacktrace[0xbf400210] recurse() /home/laruence/test.php:3[0xbf400440] recurse() /home/laruence/test.php:3[0xbf400670] recurse() /home/laruence/test.php:3[0xbf4008a0] recurse() /home/laruence/test.php:3[0xbf400ad0] recurse() /home/laruence/test.php:3[0xbf400d00] recurse() /home/laruence/test.php:3[0xbf400f30] recurse() /home/laruence/test.php:3[0xbf401160] recurse() /home/laruence/test.php:3..... 关于.gdbinit, 是一段小小的脚本文件, 定义了一些方便我们去调试PHP的Core, 大家也可以用文本编辑器打开, 看看里面定义的一些快捷的命令, 一般来说, 我常用的有: zbacktraceprint_ht**系列zmemcheck OK, 回归正题, 我们现在知道, 问题发生在/home/laruence/test.php的recurse函数的递归调用上了. 现在, 让我们来看看, 在调用这个函数的时候的参数是什么? PHP的参数传递是依靠一个全局Stack来完成的, 也就是EG(argument_stack), EG在非多线程情况下就是executor_globals, 它保持了很多执行状态. 而argument_statck就是参数的传递栈, 保存着对应PHP函数调用层数相当的调用参数. 要注意的是, 这个PHP函数调用堆栈(层数)不和gdb所看到的backtrace简单的一一对应, 所以参数也不能直接和gdb的backtrace对应起来, 需要单独分析: //先看看, 最后一次函数调用的参数数目是多少(gdb) p (int )*(executor_globals->argument_stack->top_element - 2)$13 = 1 //再看看, 最后一次函数调用的参数是什么(gdb) p **(zval **)(executor_globals->argument_stack->top_element - 3)$2 = {value = {lval = 22445, dval = 1.1089303420906779e-319, str = {val = 0x57ad <Address 0x57ad out of bounds>, len = 7}, ht = 0x57ad, obj = {handle = 22445, handlers = 0x7}}, refcount = 2, type = 1 '\001', is_ref = 0 '\0'} 好, 我们现在得到, 最后一次调用的参数是一个整数, 数值是22445 到了这一步, 我们就得到了这个Core发生的时刻的PHP层面的相关信息, 接下来, 就可以交给对应的PHP开发工程师来排查, 这个参数下, 可能造成的无穷大递归的原因, 从而修复这个问题..
6. 如何根据core文件中错误地址定位程序
The problem that no `core' file is created on a segmentation fault; Locate errors in the source with GDB and `core' files
linux 程序在遇到段错误(常见的是由非法访问内存引起)的时候会产生 core 文件，如果这个程序包含调试信息(编译的时候加 -g 选项)，那么使用 gdb 读取这个 core 文件可以快速定位出错的源代码。原来在某软件公司实习的时候(用 RedHat Enterprise Linux)觉得这样非常方便查错，但我自己用的 Debian GNU/Linux 却默认不生成这个文件。
检查以后发现原因是 core 文件最大尺寸(用 ulimit -c 查看)是 0，把它设置成非 0 值就可以了，如:
ulimit -c 2048(设置 core 文件最大尺寸为 2048 blocks，1block=512bytes，因此这里设置的其实是 1MiB)
ulimit -c unlimited(不限 core 文件尺寸)
附:用 gdb 根据 core mp 文件定位错误的办法。
用这个程序作一个测试:
int foo (int *p)
{
return *p;
}
main()
{
foo (0);
}
derek@dli: /tmp $ gcc -g a.c
derek@dli: /tmp $ ./a.out
段错误 (core mped)
derek@dli: /tmp $ gdb ./a.out -c core
(这里略去约十行其他信息)
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804834a in foo (p=0x0) at a.c:3
3 return *p;
如果再输入一条命令 bt，就可以看得清清楚楚错误是在什么时机产生的:
(gdb) bt
#0 0x0804834a in foo (p=0x0) at a.c:3
#1 0x0804836b in main () at a.c:8
不能有比这更清楚的错误信息了!如果是在 Windows 下，就老老实实 Trace and Step 吧。
7. 如何查看程序被哪个版本编译器编译的linux-gcc
那是不可能的，除非你加入了调试信息，也就是编译的时候加入了-g参数，然后用gdb调试就可以显示。最大程度上查看一个elf文件信息。
｛
readelf -Wa a.out | head
readelf -wi a.out
readelf -p .comment a.out
objmp -s --section .comment audioplayer
｝
如下：
[root@localhost rootfs]# readelf -Wa bin/gzip
复制代码
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0xa080
Start of program headers: 52 (bytes into file)
Start of section headers: 1975444 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 24
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.ABI-tag NOTE 000080f4 0000f4 000020 00 A 0 0 4
[ 2] .init PROGBITS 00008114 000114 00000c 00 AX 0 0 4
[ 3] .text PROGBITS 00008120 000120 17fcfc 00 AX 0 0 16
[ 4] __libc_freeres_fn PROGBITS 00187e1c 17fe1c 000f20 00 AX 0 0 4
[ 5] __libc_thread_fre PROGBITS 00188d3c 180d3c 0000e4 00 AX 0 0 4
[ 6] .fini PROGBITS 00188e20 180e20 000008 00 AX 0 0 4
[ 7] .rodata PROGBITS 00188e28 180e28 058147 00 A 0 0 8
[ 8] __libc_subfreeres PROGBITS 001e0f70 1d8f70 00005c 00 A 0 0 4
[ 9] __libc_atexit PROGBITS 001e0fcc 1d8fcc 000004 00 A 0 0 4
[10] __libc_thread_sub PROGBITS 001e0fd0 1d8fd0 000008 00 A 0 0 4
[11] .ARM.extab PROGBITS 001e0fd8 1d8fd8 001b04 00 A 0 0 4
[12] .ARM.exidx ARM_EXIDX 001e2adc 1daadc 006ea8 00 AL 3 0 4
[13] .tdata PROGBITS 001f1984 1e1984 000018 00 WAT 0 0 4
[14] .tbss NOBITS 001f199c 1e199c 000034 00 WAT 0 0 4
[15] .init_array INIT_ARRAY 001f199c 1e199c 000004 00 WA 0 0 4
[16] .fini_array FINI_ARRAY 001f19a0 1e19a0 000008 00 WA 0 0 4
[17] .jcr PROGBITS 001f19a8 1e19a8 000004 00 WA 0 0 4
[18] .data.rel.ro PROGBITS 001f19ac 1e19ac 00002c 00 WA 0 0 4
[19] .got PROGBITS 001f19d8 1e19d8 00007c 04 WA 0 0 4
[20] .data PROGBITS 001f1a58 1e1a58 0008f7 00 WA 0 0 8
[21] .bss NOBITS 001f2350 1e234f 004828 00 WA 0 0 8
[22] __libc_freeres_pt NOBITS 001f6b78 1e234f 00003c 00 WA 0 0 4
[23] .ARM.attributes ARM_ATTRIBUTES 00000000 1e234f 00002b 00 0 0 1
[24] .shstrtab STRTAB 00000000 1e237a 000118 00 0 0 1
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01 .note.ABI-tag .init .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata __libc_subfreeres __libc_atexit __libc_thread_subfreeres .ARM.extab .ARM.exidx
02 .tdata .init_array .fini_array .jcr .data.rel.ro .got .data .bss __libc_freeres_ptrs
03 .note.ABI-tag
04 .tdata .tbss
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align8_needed: Yes
Tag_ABI_align8_preserved: Yes, except leaf SP
Tag_ABI_enum_size: int
Tag_unknown_44: 1 (0x1)
复制代码
How to retrieve the GCC version used to compile a given ELF executable? http://stackoverflow.com/questions/2387040/how-to-retrieve-the-gcc-version-used-to-compile-a-given-elf-executable
QUES: I'd like to retrieve the GCC version used to compile a given executable. I tried readelf but didn't get the information. Any thoughts?
ANS: To complete what others have said: it's not stored in the object (or exe) file, unless you compile with debugging information! (option -g). If you compile with debug info, you can get it back with readelf:
复制代码
[root@localhost test]# gcc a.c
[root@localhost test]# readelf -wi a.out
[root@localhost test]# gcc a.c -g
[root@localhost test]# readelf -wi a.out
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length: 135
Version: 2
Abbrev Offset: 0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_stmt_list : 0
DW_AT_high_pc : 0x400453
DW_AT_low_pc : 0x400448
DW_AT_procer : GNU C 4.1.2 20080704 (Red Hat 4.1.2-55)
DW_AT_language : 1 (ANSI C)
DW_AT_name : a.c
DW_AT_comp_dir : /work/farsight/test
<1><61>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : main
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_prototyped : 1
DW_AT_type : <83>
DW_AT_low_pc : 0x400448
DW_AT_high_pc : 0x400453
DW_AT_frame_base : 0 (location list)
<1><83>: Abbrev Number: 3 (DW_TAG_base_type)
DW_AT_name : int
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
复制代码
ANS2：
8. 用keil编译C时出现 non-address/-consatant initializer 该怎么办啊求教！！
你定义的数组用code修饰了以后是放在rom上，这样是在编译以后就固定的。
而你的数组赋值的时候用的是全局变量动态的。
所以出现无法初始化的error。
你要么去掉code，要么把数组用常量表示。