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，要麼把數組用常量表示。