Rene, >If you look at the comment preceding that bit, you'll see it say that the >code is "mostly" (?) position independent and although I don't know ARM >assembly nor have an ARM toolchain installed, I bet that if you look at the
>actual generated code, you'll see it generating the branch target as a >relative target -- that is, as a "jump program_counter +/- offset", where >"offset" is the only thing that is encoded in the instruction stream. In >that case, it's only the _difference_ "target - program_counter" that is >relevant and not any absolute values. That makes sense. Thanks a lot. So position independent code is one wherein all the branch instructions are PC relative. Right? And is the entire Linux Kernel Position Independent Code??? Thanks - A. On 1/24/08, Rene Herman <[EMAIL PROTECTED]> wrote: > > On 24-01-08 11:31, sahlot arvind wrote: > > > I compiled kernel for ARM processor. > > I am trying to trace kernel control flow. I am looking at file > > "arch/arm/kernel/head.S" . Code starting with > > > > ------------------- > > __INIT > > .type stext, #function > > ENTRY(stext) > > mov r12, r0 > > mov r0, #PSR_F_BIT | PSR_I_BIT | MODE_SVC @ make sure svc > mode > > msr cpsr_c, r0 @ and all irqs disabled > > bl __lookup_processor_type > > ------------------- > > > > > > Question comes up at last line (bl __lookup_processor_type) of this > > code snippet. > > If I look into System.map file I find the address of symbol > > "__lookup_processor_type" as c0008168 and as per my understanding kernel > > > image is loaded in the memory starting after first 1 MB. > > On x86 that's the normal/classic arrangement at least yes. Don't know > about > ARM actually, but that sounds likely. > > > Here I assume that I am correctly interpreting System.map file. Please > > let me know if I am misinterpreting this file. I assume that first > column > > contains address, second I dont know (please tell) and third symbol. > > Right? > > Right. It's a generic symbol file, for which "man nm" will provide more > detail. > > > Now since MMU is disabled at this point of time how come we can branch > > to "__lookup_processor_type" whose address is after 3 GB??? What I mean > > is - at this stage page tables have not been setup then how can we > > access a symbol which has been assigned address as c0008168 and lying in > > some memory region??? > > Basically -- you get to ignore the symbol file in this case. The symbol > file > is generated _assuming_ the kernel runs at 3G since that's where it's at > in > virtual terms after paging has been enabled but it's not being told that > for > the bit that runs pre-paging such isn't in fact correct. > > If you look at the comment preceding that bit, you'll see it say that the > code is "mostly" (?) position independent and although I don't know ARM > assembly nor have an ARM toolchain installed, I bet that if you look at > the > actual generated code, you'll see it generating the branch target as a > relative target -- that is, as a "jump program_counter +/- offset", where > "offset" is the only thing that is encoded in the instruction stream. In > that case, it's only the _difference_ "target - program_counter" that is > relevant and not any absolute values. > > Rene. > >
