Thanks Russell. I will re-try and get back in case dont understand. - A
On Sat, Apr 26, 2008 at 2:09 AM, Russell King - ARM Linux < [EMAIL PROTECTED]> wrote: > On Fri, Apr 25, 2008 at 02:31:20PM +0530, sahlot arvind wrote: > > Guys, > > > > I am trying to understand the flow of control when an interrupt comes. > > I am reading linux-2.6.24 src code and looking at > > arch/arm/kernel/entry-armv.S. > > At the bottom of this file I see the vector table as below - > > > > __vectors_start: > > swi SYS_ERROR0 > > b vector_und + stubs_offset > > ldr pc, .LCvswi + stubs_offset > > b vector_pabt + stubs_offset > > b vector_dabt + stubs_offset > > b vector_addrexcptn + stubs_offset > > b vector_irq + stubs_offset > > b vector_fiq + stubs_offset > > > > .globl __vectors_end > > > > > > Here is not 'stubs_offset' a constant? and after seeing an IRQ where are > we > > branching by doing ' b vector_irq + stubs_offset' and what is the > flow of > > control??? > > It's all rather mystical if you don't understand the ARM instruction set. > > 1. 'b' is a branch instruction. All branches are relative to the > current PC. > > 2. the code is not executed in the location where you find it in > the kernel. It is copied to other locations in memory. Other > code (between __stubs_start and __stubs_end) is copied to 512 > bytes above the start of the vectors, and these branch instructions > branch to that other code. > > 3. __stubs_offset is just a correction factor to convert the branches > to point at the correct _relative_ position when they're copied to > their proper location in memory. > > The simple way to _read_ the code is to ignore the 'stubs_offset' and just > follow the branch instruction to vector_irq: > > /* > * Interrupt dispatcher > */ > vector_stub irq, IRQ_MODE, 4 > > and then look at what vector_stub expands to. > -- http://linuxexplained.blogspot.com
