标题 | 阅读 | 评论 | 转发 | 发布日期 | |
---|---|---|---|---|---|
对比objdump与readelf | 2122 | 2 | 1 | 2011-05-22 | |
Linux下库函数动态链接过程分析-结合glibc-2.11源码 | 2442 | 0 | 1 | 2011-05-22 | |
【推荐】 printf 打印signed char 与unsigned char 之区别 | 22944 | 8 | 1 | 2011-05-05 | |
编译选项 | 769 | 0 | 0 | 2011-04-08 | |
linux 内核编码格式 | 977 | 0 | 0 | 2011-03-18 | |
Google Objective-C Style Guide | 996 | 0 | 0 | 2011-03-08 | |
c stdlib 库函数 | 711 | 1 | 0 | 2011-03-01 | |
source insight的快捷键总结 | 619 | 0 | 0 | 2010-02-05 | |
数据结构复习--串操作(20081209) | 1230 | 0 | 0 | 2008-12-08 | |
C语言定义的语法 | 1111 | 0 | 0 | 2008-11-14 | |
static的使用! (转载) | 788 | 0 | 0 | 2008-03-19 | |
const的使用! (转载) | 920 | 0 | 0 | 2008-03-19 | |
inline的使用 | 3073 | 0 | 0 | 2008-03-19 | |
C语言中的volatile关键字(转载) | 931 | 0 | 0 | 2008-03-19 |
redglass2008-09-10 13:12
我做2440系统的移植的时候发现这样的问题 在一开始进行到setup_processor这个函数的时候(arch/arm/kernel/setup.c)跟踪看了一下list = lookup_processor_type();得到的指针是null,跟踪进去看汇编,就是head.s中的那个__lookup_processor_type函数,代码如下,其中把各个寄存器的值都打出来了,看了都没什么问题,在1:后答应看到的r3,r4,r9都能和arch/arm/mm/proc-arm920.s对应上(后面有代码),应该能正常的到2:,但是怎么在c里面的那个语句获得不到该得到的值呢?请知道的话帮我解释一下吧。谢谢了 __lookup_processor_type: adr r3, 3f ldmda r3, {r5, r6, r9} sub r3, r3, r9 @ get offset between virt&phys add r5, r5, r3 @ convert virt addresses to add r6, r6, r3 @ physical address space mrc p15, 0, r9, c0, c0 @ get processor id 1: ldmia r5, {r3, r4} @ value, mask and r4, r4, r9 @ mask wanted bits teq r3, r4 beq 2f add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list) cmp r5, r6 blo 1b mov r5, #0 @ unknown processor 2: mov pc, lr __arm920_proc_info: .long 0x41009200 .long 0xff00fff0 .long PMD_TYPE_SECT | \ PMD_SECT_BUFFERABLE | \ PMD_SECT_CACHEABLE | \ PMD_BIT4 | \ PMD_SECT_AP_WRITE | \ PMD_SECT_AP_READ b __arm920_setup .long cpu_arch_name .long cpu_elf_name .long HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB .long cpu_arm920_name .long arm920_processor_functions .long v4wbi_tlb_fns .long v4wb_user_fns #ifndef CONFIG_CPU_DCACHE_WRITETHROUGH .long arm920_cache_fns #else .long v4wt_cache_fns #endif .size __arm920_proc_info, . - __arm920_proc_info