Stack Frame Calc Problem in head_4xx.S

Stack Frame Calc Problem in head_4xx.S

[Jerry Walden]

Greetings:

I am having trouble understanding what is happening to my stack pointer.

At line 1 r1 = 0x03f9_ebe8

After line 15 executes r1 = 0xc00f4ff0
which seems fine so far (according to the map file it is pointing to the
proper location)

After line 16 executes r1=0xc00f6ff0
which is still within the bounds of init_task_union

After line 17 execute r1 = 0xc00f6fe0 which seems like a problem to me,
because it is not with the
bounds of init_task_union - (see map file below)

I would expect r1 to be within the bounds of init_task_union after this code
is executed -
is my guess correct?  If so how is it possible that line 17 comes up with
the result
that it did?

TASK_UNION_SIZE = 8192
STACK_FRAME_OVERHEAD = 16

Thanks for any help

Jerry

1 start_here:
2
3	/* ptr to current */
4	lis	r2,init_task_union@h
5	ori	r2,r2,init_task_union@l
6
7	/* ptr to phys current thread */
8	tophys(r4,r2)
9	addi	r4,r4,THREAD	/* init task's THREAD */
10	mtspr	SPRG3,r4
11	li	r3,0
12	mtspr	SPRG2,r3	/* 0 => r1 has kernel sp */
13
14	/* stack */
15	addi	r1,r2,TASK_UNION_SIZE
16	li	r0,0
17	stwu	r0,-STACK_FRAME_OVERHEAD(r1)


c00f4ff0 D init_task_union
c00f6ff0 d aligninfo
c00f70f0 D cpuinfo_op
c00f7100 D cpu_specs
c00f7280 D ppc_htab_operations



Jerry Walden
Program Manager
Digital Atlantic Inc
http://www.digitalatlantic.com
jwalden@digitalatlantic.com
1-877-494-6073 x407
cell - 703-431-2413


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stack Frame Calc Problem in head_4xx.S

[Gary D. Thomas]

On Sat, 2003-05-03 at 15:20, Jerry Walden wrote:
> Greetings:
>
> I am having trouble understanding what is happening to my stack pointer.
>
> At line 1 r1 = 0x03f9_ebe8
>
> After line 15 executes r1 = 0xc00f4ff0
> which seems fine so far (according to the map file it is pointing to the
> proper location)
>
> After line 16 executes r1=0xc00f6ff0
> which is still within the bounds of init_task_union
>
> After line 17 execute r1 = 0xc00f6fe0 which seems like a problem to me,
> because it is not with the
> bounds of init_task_union - (see map file below)
>

Why do you think this?  It seems that init_task_union comprises the
space from 0xc00f4ff0..0xc00f6ff0.  That value is certainly within
that range.

> I would expect r1 to be within the bounds of init_task_union after this code
> is executed -
> is my guess correct?  If so how is it possible that line 17 comes up with
> the result
> that it did?

Read how 'stwu' works.  After the store takes place, r1 is updated
with the new value.  In other words
  stwu r0,-STACK_FRAME_OVERHEAD(r1)
means
  [r1] = r0
  r1 = r1 - STACK_FRAME_OVERHEAD(r1)
which is exactly the results you are getting.

>
> TASK_UNION_SIZE = 8192
> STACK_FRAME_OVERHEAD = 16
>
> Thanks for any help
>
> Jerry
>
> 1 start_here:
> 2
> 3	/* ptr to current */
> 4	lis	r2,init_task_union@h
> 5	ori	r2,r2,init_task_union@l
> 6
> 7	/* ptr to phys current thread */
> 8	tophys(r4,r2)
> 9	addi	r4,r4,THREAD	/* init task's THREAD */
> 10	mtspr	SPRG3,r4
> 11	li	r3,0
> 12	mtspr	SPRG2,r3	/* 0 => r1 has kernel sp */
> 13
> 14	/* stack */
> 15	addi	r1,r2,TASK_UNION_SIZE
> 16	li	r0,0
> 17	stwu	r0,-STACK_FRAME_OVERHEAD(r1)
>
>
> c00f4ff0 D init_task_union
> c00f6ff0 d aligninfo
> c00f70f0 D cpuinfo_op
> c00f7100 D cpu_specs
> c00f7280 D ppc_htab_operations
>
>
>
> Jerry Walden
> Program Manager
> Digital Atlantic Inc
> http://www.digitalatlantic.com
> jwalden@digitalatlantic.com
> 1-877-494-6073 x407
> cell - 703-431-2413
>
>
--
Gary D. Thomas <gary.thomas@mind.be>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Stack Frame Calc Problem in head_4xx.S

[Jerry Walden]

Duh! - I was debugging late last night, and I must have misread the value
in r1.

Thanks for pointing out the obvious, and correcting me.

The problem I am having is that I set a breakpoint with my
BDI-2000 at start kernel, and the first instruction is:

stwu r1, -32(r1)

If I step through that instruction, I get a debug exception.
If I just "go" the console hangs, and when I halt the processor
with the BDI, it is still at a debug exception (PC=0x2204).

I can't figure out what is going on.  I've been trolling through
the lists for other folks that may have had a similar problem,
and have found several with a similar problem - I found a response
from Wolfgang Denk:

"Well, did you (a) follow the description in the BDI2000 manual and
initialize the page table pointer manually, or (b) did you use a
kernel which has the necessary extension to do it automagically?
Wolfgang Denk"

and my answer is that I am running with the Monta Vista Linux
2.4.18_MVL30, with V1.11 of the BDI-2000 firmware, and I am
booting with the latest version of u-boot.  The kernel
in head_4xx.S has "the automagic extension" that sets the
Abatron PTE pointers.

So I am tearing my hair out...


Jerry Walden
-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Gary D.
Thomas
Sent: Saturday, May 03, 2003 6:22 PM
To: jwalden@digitalatlantic.com
Cc: Linux PPC embedded
Subject: Re: Stack Frame Calc Problem in head_4xx.S



On Sat, 2003-05-03 at 15:20, Jerry Walden wrote:
> Greetings:
>
> I am having trouble understanding what is happening to my stack pointer.
>
> At line 1 r1 = 0x03f9_ebe8
>
> After line 15 executes r1 = 0xc00f4ff0
> which seems fine so far (according to the map file it is pointing to the
> proper location)
>
> After line 16 executes r1=0xc00f6ff0
> which is still within the bounds of init_task_union
>
> After line 17 execute r1 = 0xc00f6fe0 which seems like a problem to me,
> because it is not with the
> bounds of init_task_union - (see map file below)
>

Why do you think this?  It seems that init_task_union comprises the
space from 0xc00f4ff0..0xc00f6ff0.  That value is certainly within
that range.

> I would expect r1 to be within the bounds of init_task_union after this
code
> is executed -
> is my guess correct?  If so how is it possible that line 17 comes up with
> the result
> that it did?

Read how 'stwu' works.  After the store takes place, r1 is updated
with the new value.  In other words
  stwu r0,-STACK_FRAME_OVERHEAD(r1)
means
  [r1] = r0
  r1 = r1 - STACK_FRAME_OVERHEAD(r1)
which is exactly the results you are getting.

>
> TASK_UNION_SIZE = 8192
> STACK_FRAME_OVERHEAD = 16
>
> Thanks for any help
>
> Jerry
>
> 1 start_here:
> 2
> 3	/* ptr to current */
> 4	lis	r2,init_task_union@h
> 5	ori	r2,r2,init_task_union@l
> 6
> 7	/* ptr to phys current thread */
> 8	tophys(r4,r2)
> 9	addi	r4,r4,THREAD	/* init task's THREAD */
> 10	mtspr	SPRG3,r4
> 11	li	r3,0
> 12	mtspr	SPRG2,r3	/* 0 => r1 has kernel sp */
> 13
> 14	/* stack */
> 15	addi	r1,r2,TASK_UNION_SIZE
> 16	li	r0,0
> 17	stwu	r0,-STACK_FRAME_OVERHEAD(r1)
>
>
> c00f4ff0 D init_task_union
> c00f6ff0 d aligninfo
> c00f70f0 D cpuinfo_op
> c00f7100 D cpu_specs
> c00f7280 D ppc_htab_operations
>
>
>
> Jerry Walden
> Program Manager
> Digital Atlantic Inc
> http://www.digitalatlantic.com
> jwalden@digitalatlantic.com
> 1-877-494-6073 x407
> cell - 703-431-2413
>
>
--
Gary D. Thomas <gary.thomas@mind.be>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stack Frame Calc Problem in head_4xx.S

[Erik Christiansen]

On Sat, May 03, 2003 at 05:20:51PM -0400, Jerry Walden wrote:
>
> After line 15 executes r1 = 0xc00f4ff0
> which seems fine so far (according to the map file it is pointing to the
> proper location)
>
> After line 16 executes r1=0xc00f6ff0
> which is still within the bounds of init_task_union
>
> After line 17 execute r1 = 0xc00f6fe0 which seems like a problem to me,

   The code seems to be doing exactly what you ask it to.

   stwu updates r1 by the offset, after completing the store. (That's
   what the "u" is for.)

   Given:

> STACK_FRAME_OVERHEAD = 16

   How can you expect any other result?:

> 17	stwu	r0,-STACK_FRAME_OVERHEAD(r1)

   If this is as intended, then your problem lies earlier, it appears.
   (But it sounds a little like you're unaware that you're modifying the
   stack pointer, not just indexing from it.)

Regards,
Erik

--
 _,-_|\    Erik Christiansen
/      \   Registered (Debian) Linux User #216862
\_,-.__/
      v

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/