[Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Gauresh Rane]

Hi,

I am working on developing a simulator on qemu. I am faced with a bug and I have tried solving it for three days now with no success:
Here is my problem:
I trying to simulate LPC 1768 cortex m3 based processor on qemu. But I am unable to get beyond the libc_init_array in the newlib. 
My qemu cpu jumps to program counter 0 when on jump inside init function of __libc_init_array of newlib.

Here is the disassembly code for init:

Called from libc_init_array

0000042c <_init>:
291  42c:   b5f8        push    {r3, r4, r5, r6, r7, lr}
292  42e:   bf00        nop
293  430:   bcf8        pop {r3, r4, r5, r6, r7}
294  432:   bc08        pop {r3}
295  434:   469e        mov lr, r3
296  436:   4770        bx  lr

I stepped through the intermediate code generation in qemu which looks fine to me.

Also, I am not able to figure one part in qemu that is how is the cpu environment like registers for a processor updated.

Any help would be highly appreciated.

Thanks,

Regards,


Gauresh Rane
Grad Student
CS Department
UCLA

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Peter Maydell]

On 25 November 2011 10:27, Gauresh Rane <gdrane@cs.ucla.edu> wrote:
> I am working on developing a simulator on qemu. I am faced with a bug and I have tried solving it for three days now with no success:
> Here is my problem:
> I trying to simulate LPC 1768 cortex m3 based processor on qemu. But I am unable to get beyond the libc_init_array in the newlib.
> My qemu cpu jumps to program counter 0 when on jump inside init function of __libc_init_array of newlib.

On M profile, suddenly finding yourself at address zero usually means
that (1) the core tried to take an exception and (2) you didn't
fill in the vector table so the address in the table for whichever
exception it was was zero.

Which instruction in the block is causing the problem?
(If this is the first instruction where you tried to push something,
has the stack pointer been set up correctly?)

-- PMM

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Gauresh Rane]

Hey,

Thanks for the reply.
The instruction that is causing problem is
436: bx lr

On single stepping and logging the trace I see that the lr has been set correctly to jump back, in the beginning of the block and also the microinstructions instructions generated match the following disassembly of the elf.

290 0000042c <_init>:
291  42c:   b5f8        push    {r3, r4, r5, r6, r7, lr}
292  42e:   bf00        nop
293  430:   bcf8        pop {r3, r4, r5, r6, r7}
294  432:   bc08        pop {r3}
295  434:   469e        mov lr, r3
296  436:   4770        bx  lr

Also all the registers which are pushed to the stack, "r3, r4, r5, r6, r7, lr" are cleared to zero

After bx lr, pc becomes 0, it does not find any code there thus throws a usage exception and runs Usage fault handler in a loop.

What do you mean by setting up the stack? Is it done seperately? Other bx lr calls are successfully executed.

Also I am not understanding where processor state values updated in qemu code.

Thanks,

Gauresh Rane


----- Original Message -----
From: "Peter Maydell" <peter.maydell@linaro.org>
To: "Gauresh Rane" <gdrane@cs.ucla.edu>
Cc: qemu-devel@nongnu.org
Sent: Friday, November 25, 2011 3:39:02 AM
Subject: Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

On 25 November 2011 10:27, Gauresh Rane <gdrane@cs.ucla.edu> wrote:
> I am working on developing a simulator on qemu. I am faced with a bug and I have tried solving it for three days now with no success:
> Here is my problem:
> I trying to simulate LPC 1768 cortex m3 based processor on qemu. But I am unable to get beyond the libc_init_array in the newlib.
> My qemu cpu jumps to program counter 0 when on jump inside init function of __libc_init_array of newlib.

On M profile, suddenly finding yourself at address zero usually means
that (1) the core tried to take an exception and (2) you didn't
fill in the vector table so the address in the table for whichever
exception it was was zero.

Which instruction in the block is causing the problem?
(If this is the first instruction where you tried to push something,
has the stack pointer been set up correctly?)

-- PMM

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Peter Maydell]

On 25 November 2011 12:33, Gauresh Rane <gdrane@cs.ucla.edu> wrote:
> Thanks for the reply.
> The instruction that is causing problem is
> 436: bx lr
>
> On single stepping and logging the trace I see that the lr has been set
> correctly to jump back, in the beginning of the block and also the
> microinstructions instructions generated match the following disassembly
> of the elf.

What is the expected return address in LR ? (In particular,
check that it has the low bit set to indicate a Thumb mode
destination.)

> Also all the registers which are pushed to the stack,
> "r3, r4, r5, r6, r7, lr" are cleared to zero

That is odd. I wonder if the processor is resetting for some reason.

> After bx lr, pc becomes 0, it does not find any code there thus
> throws a usage exception and runs Usage fault handler in a loop.

(Actually the UsageFault when PC==0 is because it's trying to execute
in the non-existent ARM mode.)

> What do you mean by setting up the stack? Is it done seperately?

I mean "setting SP to a value such that you can push registers
without causing a memory fault". If you're not failing on the push
instructions then you've probably got a valid stack.

> Also I am not understanding where processor state values updated
> in qemu code.

All over the place. In particular for register value changes
the generated code will include direct loads and stores to
the bits of the CPUState structure containing registers.
(Changes to PC are special too.)

-- PMM

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Max Filippov]

>> Also all the registers which are pushed to the stack,
>> "r3, r4, r5, r6, r7, lr" are cleared to zero
>
> That is odd. I wonder if the processor is resetting for some reason.

Another other possibility is stack pointer pointing to a region w/o
underlying physical memory.

-- 
Thanks.
-- Max

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Gauresh Rane]

This is how it looks:

Hi,

Thanks for the help.

Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
557                         next_tb = tcg_qemu_tb_exec(env, tc_ptr);
(gdb) p/x env->regs
$13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x40000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
(gdb) s
558                         if ((next_tb & 3) == 2) {
(gdb) p/x env->regs
$14 = {0x10048000, 0x20, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fb8, 0x560d, 0x0}

How to check access to unallocated memory? It's not seg faulting.

Thanks,

Regards,

Gauresh Rane
Grad Student
CS Department
UCLA

----- Original Message -----
From: "Max Filippov" <jcmvbkbc@gmail.com>
To: "Peter Maydell" <peter.maydell@linaro.org>
Cc: "Gauresh Rane" <gdrane@cs.ucla.edu>, qemu-devel@nongnu.org
Sent: Friday, November 25, 2011 5:04:15 AM
Subject: Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

>> Also all the registers which are pushed to the stack,
>> "r3, r4, r5, r6, r7, lr" are cleared to zero
>
> That is odd. I wonder if the processor is resetting for some reason.

Another other possibility is stack pointer pointing to a region w/o
underlying physical memory.

-- 
Thanks.
-- Max

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Max Filippov]

> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
> 557                         next_tb = tcg_qemu_tb_exec(env, tc_ptr);
> (gdb) p/x env->regs
> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x40000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
> (gdb) s
> 558                         if ((next_tb & 3) == 2) {
> (gdb) p/x env->regs
> $14 = {0x10048000, 0x20, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fb8, 0x560d, 0x0}
> 
> How to check access to unallocated memory? It's not seg faulting.

290 0000042c <_init>:
291  42c:   b5f8        push    {r3, r4, r5, r6, r7, lr}

set breakpoint here and see with x/6wx $sp whether saved register values are good.

292  42e:   bf00        nop
293  430:   bcf8        pop {r3, r4, r5, r6, r7}
294  432:   bc08        pop {r3}
295  434:   469e        mov lr, r3
296  436:   4770        bx  lr

Or you can find physical address under $sp, and then via monitor command 'info mtree' check whether there's physical memory by that address.

To find physical address you can either uncomment #define DEBUG_TLB in the exec.c to make it print virtual-to-physical translations or
set breakpoint at cpu_arm_handle_mmu_fault and inspect address and phys_addr values.

Thanks.
-- Max

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Peter Maydell]

On 25 November 2011 15:35, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
>> 557                         next_tb = tcg_qemu_tb_exec(env, tc_ptr);
>> (gdb) p/x env->regs
>> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x40000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
>> (gdb) s
>> 558                         if ((next_tb & 3) == 2) {
>> (gdb) p/x env->regs
>> $14 = {0x10048000, 0x20, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fb8, 0x560d, 0x0}
>>
>> How to check access to unallocated memory? It's not seg faulting.
>
> 290 0000042c <_init>:
> 291  42c:   b5f8        push    {r3, r4, r5, r6, r7, lr}
>
> set breakpoint here and see with x/6wx $sp whether saved register values are good.

To clarify this a bit: that means "set a breakpoint in an ARM gdb attached
to qemu's gdb-stub interface". That gdb will see the view of the guest
CPU, whereas connecting an x86 gdb directly to qemu you're looking at
qemu's internal data structures, which can be more confusing.

-- PMM

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Gauresh Rane]

The problem was indeed with the stack. It's just doing a fake push, that is the environment variables are updated but the the variables are not loaded into the stack. I see the values in the stack always are zero.

I am trying to figure out what might be the reason for this.

Thanks for the help,

Regards,

Gauresh Rane
Grad Student
CS Department
UCLA

----- Original Message -----
From: "Peter Maydell" <peter.maydell@linaro.org>
To: "Max Filippov" <jcmvbkbc@gmail.com>
Cc: "Gauresh Rane" <gdrane@cs.ucla.edu>, qemu-devel@nongnu.org
Sent: Friday, November 25, 2011 7:40:52 AM
Subject: Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

On 25 November 2011 15:35, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
>> 557                         next_tb = tcg_qemu_tb_exec(env, tc_ptr);
>> (gdb) p/x env->regs
>> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x40000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
>> (gdb) s
>> 558                         if ((next_tb & 3) == 2) {
>> (gdb) p/x env->regs
>> $14 = {0x10048000, 0x20, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fb8, 0x560d, 0x0}
>>
>> How to check access to unallocated memory? It's not seg faulting.
>
> 290 0000042c <_init>:
> 291  42c:   b5f8        push    {r3, r4, r5, r6, r7, lr}
>
> set breakpoint here and see with x/6wx $sp whether saved register values are good.

To clarify this a bit: that means "set a breakpoint in an ARM gdb attached
to qemu's gdb-stub interface". That gdb will see the view of the guest
CPU, whereas connecting an x86 gdb directly to qemu you're looking at
qemu's internal data structures, which can be more confusing.

-- PMM

Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

[Gauresh Rane]

Works Like a charm....The memory at that place was indeed not allocated.
Thanks for your help.

Regards,

Gauresh Rane
Grad Student
CS Department
UCLA

----- Original Message -----
From: "Peter Maydell" <peter.maydell@linaro.org>
To: "Max Filippov" <jcmvbkbc@gmail.com>
Cc: "Gauresh Rane" <gdrane@cs.ucla.edu>, qemu-devel@nongnu.org
Sent: Friday, November 25, 2011 7:40:52 AM
Subject: Re: [Qemu-devel] Problem with translating on ARM and Qemu beginner question

On 25 November 2011 15:35, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
>> 557                         next_tb = tcg_qemu_tb_exec(env, tc_ptr);
>> (gdb) p/x env->regs
>> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x40000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
>> (gdb) s
>> 558                         if ((next_tb & 3) == 2) {
>> (gdb) p/x env->regs
>> $14 = {0x10048000, 0x20, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x30, 0x10007fb8, 0x560d, 0x0}
>>
>> How to check access to unallocated memory? It's not seg faulting.
>
> 290 0000042c <_init>:
> 291  42c:   b5f8        push    {r3, r4, r5, r6, r7, lr}
>
> set breakpoint here and see with x/6wx $sp whether saved register values are good.

To clarify this a bit: that means "set a breakpoint in an ARM gdb attached
to qemu's gdb-stub interface". That gdb will see the view of the guest
CPU, whereas connecting an x86 gdb directly to qemu you're looking at
qemu's internal data structures, which can be more confusing.

-- PMM