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.
>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 <rene.herman@xxxxxxxxxxxx
> 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.
