[Qemu-devel] [ARM] add with PC in argument

[Qemu-devel] [ARM] add with PC in argument

[claude vittoria]

Hello,

I got a problem in an IRQ handler of mutek OS 
(https://www-asim.lip6.fr/trac/mutekh), target ARM Integrator/CM 
922T-XA10. I try to port it on Qemu. A porting has been done for Skyeyes

So in qemu I don't get the same comportement. The add of lr = pc + 4 
gives lr = pc + 8 into qemu.
I think that s->pc += 4 at start of disas_arm_insn alters the result.
Could you confirm ?

0x7c    add    lr, pc, #4
0x80    ldr    pc, =SystemInterrupt

0x84    ldr    r3, [sp, #PSR_OFF]  <= never executed in Qemu
0x88    msr    spsr_cxsf, r3        @ put cpsr in SPSR
0x8c    ldmia    sp, {r0-r15}^        @ restore Context

B.R.
Claude

Re: [Qemu-devel] [ARM] add with PC in argument

[Daniel Jacobowitz]

On Sun, Feb 24, 2008 at 01:57:04PM +0100, claude vittoria wrote:
> Hello,
>
> I got a problem in an IRQ handler of mutek OS  
> (https://www-asim.lip6.fr/trac/mutekh), target ARM Integrator/CM  
> 922T-XA10. I try to port it on Qemu. A porting has been done for Skyeyes
>
> So in qemu I don't get the same comportement. The add of lr = pc + 4  
> gives lr = pc + 8 into qemu.
> I think that s->pc += 4 at start of disas_arm_insn alters the result.
> Could you confirm ?

All ARM mode instructions (at least, on modern ARMs) read PC as
current instruction + 8.  The code you've posted looks wrong.

IIRC there were some older ARM processors with a different value.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] [ARM] add with PC in argument

[Laurent Desnogues]

On 2/24/08, claude vittoria <vittoric@wanadoo.fr> wrote:
>  So in qemu I don't get the same comportement. The add of lr = pc + 4
>  gives lr = pc + 8 into qemu.
>  I think that s->pc += 4 at start of disas_arm_insn alters the result.
>  Could you confirm ?
>
>  0x7c    add    lr, pc, #4
>  0x80    ldr    pc, =SystemInterrupt
>
>  0x84    ldr    r3, [sp, #PSR_OFF]  <= never executed in Qemu
>  0x88    msr    spsr_cxsf, r3        @ put cpsr in SPSR
>  0x8c    ldmia    sp, {r0-r15}^        @ restore Context

The add lr,pc,  #4 will put 0x88 into lr. As Daniel wrote, in ARM
mode, when an instruction which address is addr reads the
PC, it will read addr + 8.

Given the mutekh link you provide has no source code for ARM
(at least I couldn't find it), we can't guess where the ldr pc
jumps to.


Laurent

Re: [Qemu-devel] [ARM] add with PC in argument

[claude vittoria]

>On 2/24/08, claude vittoria <address@hidden> wrote:
>>  So in qemu I don't get the same comportement. The add of lr = pc + 4
>>  gives lr = pc + 8 into qemu.
>>  I think that s->pc += 4 at start of disas_arm_insn alters the result.
>>  Could you confirm ?
>>
>>  0x7c    add    lr, pc, #4
>>  0x80    ldr    pc, =SystemInterrupt
>>
>>  0x84    ldr    r3, [sp, #PSR_OFF]  <= never executed in Qemu
>>  0x88    msr    spsr_cxsf, r3        @ put cpsr in SPSR
>>  0x8c    ldmia    sp, {r0-r15}^        @ restore Context

>The add lr,pc,  #4 will put 0x88 into lr. As Daniel wrote, in ARM
>mode, when an instruction which address is addr reads the
>PC, it will read addr + 8.

>Given the mutekh link you provide has no source code for ARM
>(at least I couldn't find it), we can't guess where the ldr pc
>jumps to.

Thanks for answer.

You are right :
cited of ARM Architecture Reference Manual

"Reading the program counter
When an instruction reads the PC, the value read depends on which instruction set it comes from:
• For an ARM instruction, the value read is the address of the instruction plus 8 bytes. Bits [1:0] of this
value are always zero, because ARM instructions are always word-aligned."

Yes MutekH is the new release, I didn't take care of the release. To find the version that I m testing (porting), http://www-asim.lip6.fr/recherche/disydent/, take disydent source and you find a directory oes where are the kernel source.

I taken a short way, I was starting of http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2006/RR2006-12.pdf, source http://perso.ens-lyon.fr/nicolas.fournel/projects/ARM/mutek.html.

The port has been tested with skyeyes, it seems that a bug in source or in skyeyes, I should have read the RM before to post... as often :o)

Thanks a lot again,
Claude