Robert D'Attilio wrote:
> Hi:
> 
> I am trying to decipher the function prologue and epilogue code for setting up and unwinding the stack. The code is c+
+ and compiled under qcc (3.3.5) for our PPC405 processor. My understanding from reading the PPC EABI docs is that R1 is
 treated as the stack pointer. The steps for setting up a new stack frame are to decrement the current SP to account for
 the new frame, save the old SP in this frame (the back chain pointer) and also save the return address (Link Register) 
in the slot in the previous stack frame. All makes sense.
> However, the prologue/epilogue code for my function also includes saving/restoring register R31 which appears to be 
operating as a frame pointer. However I don't see why when R1 and R31 always seem to be pointing to the same thing. So 
my questions:
> 
> 1) Why bother with preserving R31 when one can access all fields in the current frame by just using R1?

I am no expert on the topic; but are you sure it is always 
pointing to the same thing? I did a quick test with a simple 
virtual function and in it I see r31 being saved and then 
"this" pointer loaded into it (Note: compiled with gcc 4.3.3).

4804613c:       94 21 ff b0     stwu    r1,-80(r1)
48046140:       7c 08 02 a6     mflr    r0
48046144:       90 01 00 54     stw     r0,84(r1)
48046148:       93 21 00 34     stw     r25,52(r1)
4804614c:       93 41 00 38     stw     r26,56(r1)
48046150:       93 61 00 3c     stw     r27,60(r1)
48046154:       93 81 00 40     stw     r28,64(r1)
48046158:       93 a1 00 44     stw     r29,68(r1)
4804615c:       93 c1 00 48     stw     r30,72(r1)
48046160:       93 e1 00 4c     stw     r31,76(r1)
48046164:       7c 79 1b 78     mr      r25,r3
48046168:       7c 9f 23 78     mr      r31,r4



---
Aleksandar


> 2) Why are 48 bytes reserved for the frame when less than that is actually used for storing frame header + parameters 
+ local vars?
> 
> Here is the code. Note it is a C++ function.
> 
> void Test::send(unsigned int value)
> {
> 480405f4:	94 21 ff d0 	stwu	r1,-48(r1)
> 480405f8:	7c 08 02 a6 	mflr	r0
> 480405fc:	93 e1 00 2c 	stw	r31,44(r1)
> 48040600:	90 01 00 34 	stw	r0,52(r1)
> 48040604:	7c 3f 0b 78 	mr	r31,r1
> 48040608:	90 7f 00 08 	stw	r3,8(r31)
> 4804060c:	90 9f 00 0c 	stw	r4,12(r31)
> 	unsigned int x = m_id;
> 48040610:	81 3f 00 08 	lwz	r9,8(r31)
> 48040614:	80 09 00 00 	lwz	r0,0(r9)
> 48040618:	90 1f 00 10 	stw	r0,16(r31)
> 	m_dir = value;
> 4804061c:	81 3f 00 08 	lwz	r9,8(r31)
> 48040620:	80 1f 00 0c 	lwz	r0,12(r31)
> 48040624:	90 09 00 04 	stw	r0,4(r9)
> 	Test* p = this;
> 48040628:	80 1f 00 08 	lwz	r0,8(r31)
> 4804062c:	90 1f 00 14 	stw	r0,20(r31)
> 	printf("This is me %u at 0x%p\n", x, p);
> 48040630:	3d 20 48 04 	lis	r9,18436
> 48040634:	38 69 07 c4 	addi	r3,r9,1988
> 48040638:	80 9f 00 10 	lwz	r4,16(r31)
> 4804063c:	80 bf 00 14 	lwz	r5,20(r31)
> 48040640:	4c c6 31 82 	crclr	4*cr1+eq
> 48040644:	48 00 12 f9 	bl	4804193c <_edata+0x4c>
> }
> 48040648:	81 61 00 00 	lwz	r11,0(r1)
> 4804064c:	80 0b 00 04 	lwz	r0,4(r11)
> 48040650:	7c 08 03 a6 	mtlr	r0
> 48040654:	83 eb ff fc 	lwz	r31,-4(r11)
> 48040658:	7d 61 5b 78 	mr	r1,r11
> 4804065c:	4e 80 00 20 	blr
> 
> Thanks
> robert
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25397
> 

Hi Robert,

I would guess by the look of it that the fragment is from an unoptimized
compile.  In that case r31 is the environment pointer (which points to
the function's locals); and the stack frame is big enough to hold
everything, padded to a multiple of 16 bytes (per the ELF ABI).

An optimized build wouldn't have bothered with much of that - under
4.2.4 at O2, you'd get something more like:

        00000000 <_ZN4Test4sendEj>:
           0:	7c 08 02 a6 	mflr    r0
           4:	94 21 ff f0 	stwu    r1,-16(r1)
           8:	7c 65 1b 78 	mr      r5,r3
           c:	90 01 00 14 	stw     r0,20(r1)
          10:	90 83 00 04 	stw     r4,4(r3)
          14:	80 03 00 00 	lwz     r0,0(r3)
          18:	3c 60 00 00 	lis     r3,0
          1c:	38 63 00 00 	addi    r3,r3,0
          20:	7c 04 03 78 	mr      r4,r0
          24:	4c c6 31 82 	crclr   4*cr1+eq
          28:	48 00 00 01 	bl      28 <_ZN4Test4sendEj+0x28>
          2c:	80 01 00 14 	lwz     r0,20(r1)
          30:	38 21 00 10 	addi    r1,r1,16
          34:	7c 08 03 a6 	mtlr    r0
          38:	4e 80 00 20 	blr

Regards,
Neil

On Thu, 2009-03-26 at 15:49 -0400, Robert D'Attilio wrote:
> Hi:
> 
> I am trying to decipher the function prologue and epilogue code for setting up and unwinding the stack. The code is c+
+ and compiled under qcc (3.3.5) for our PPC405 processor. My understanding from reading the PPC EABI docs is that R1 is
 treated as the stack pointer. The steps for setting up a new stack frame are to decrement the current SP to account for
 the new frame, save the old SP in this frame (the back chain pointer) and also save the return address (Link Register) 
in the slot in the previous stack frame. All makes sense.
> However, the prologue/epilogue code for my function also includes saving/restoring register R31 which appears to be 
operating as a frame pointer. However I don't see why when R1 and R31 always seem to be pointing to the same thing. So 
my questions:
> 
> 1) Why bother with preserving R31 when one can access all fields in the current frame by just using R1?
> 2) Why are 48 bytes reserved for the frame when less than that is actually used for storing frame header + parameters 
+ local vars?
> 
> Here is the code. Note it is a C++ function.
> 
> void Test::send(unsigned int value)
> {
> 480405f4:	94 21 ff d0 	stwu	r1,-48(r1)
> 480405f8:	7c 08 02 a6 	mflr	r0
> 480405fc:	93 e1 00 2c 	stw	r31,44(r1)
> 48040600:	90 01 00 34 	stw	r0,52(r1)
> 48040604:	7c 3f 0b 78 	mr	r31,r1
> 48040608:	90 7f 00 08 	stw	r3,8(r31)
> 4804060c:	90 9f 00 0c 	stw	r4,12(r31)
> 	unsigned int x = m_id;
> 48040610:	81 3f 00 08 	lwz	r9,8(r31)
> 48040614:	80 09 00 00 	lwz	r0,0(r9)
> 48040618:	90 1f 00 10 	stw	r0,16(r31)
> 	m_dir = value;
> 4804061c:	81 3f 00 08 	lwz	r9,8(r31)
> 48040620:	80 1f 00 0c 	lwz	r0,12(r31)
> 48040624:	90 09 00 04 	stw	r0,4(r9)
> 	Test* p = this;
> 48040628:	80 1f 00 08 	lwz	r0,8(r31)
> 4804062c:	90 1f 00 14 	stw	r0,20(r31)
> 	printf("This is me %u at 0x%p\n", x, p);
> 48040630:	3d 20 48 04 	lis	r9,18436
> 48040634:	38 69 07 c4 	addi	r3,r9,1988
> 48040638:	80 9f 00 10 	lwz	r4,16(r31)
> 4804063c:	80 bf 00 14 	lwz	r5,20(r31)
> 48040640:	4c c6 31 82 	crclr	4*cr1+eq
> 48040644:	48 00 12 f9 	bl	4804193c <_edata+0x4c>
> }
> 48040648:	81 61 00 00 	lwz	r11,0(r1)
> 4804064c:	80 0b 00 04 	lwz	r0,4(r11)
> 48040650:	7c 08 03 a6 	mtlr	r0
> 48040654:	83 eb ff fc 	lwz	r31,-4(r11)
> 48040658:	7d 61 5b 78 	mr	r1,r11
> 4804065c:	4e 80 00 20 	blr
> 
> Thanks
> robert
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25397
> 

Btw if you trying to get backtrace we have a library that does that.

Robert D'Attilio wrote:
> Hi:
> 
> I am trying to decipher the function prologue and epilogue code for setting up and unwinding the stack. The code is c+
+ and compiled under qcc (3.3.5) for our PPC405 processor. My understanding from reading the PPC EABI docs is that R1 is
 treated as the stack pointer. The steps for setting up a new stack frame are to decrement the current SP to account for
 the new frame, save the old SP in this frame (the back chain pointer) and also save the return address (Link Register) 
in the slot in the previous stack frame. All makes sense.
> However, the prologue/epilogue code for my function also includes saving/restoring register R31 which appears to be 
operating as a frame pointer. However I don't see why when R1 and R31 always seem to be pointing to the same thing. So 
my questions:
> 
> 1) Why bother with preserving R31 when one can access all fields in the current frame by just using R1?
> 2) Why are 48 bytes reserved for the frame when less than that is actually used for storing frame header + parameters 
+ local vars?
> 
> Here is the code. Note it is a C++ function.
> 
> void Test::send(unsigned int value)
> {
> 480405f4:	94 21 ff d0 	stwu	r1,-48(r1)
> 480405f8:	7c 08 02 a6 	mflr	r0
> 480405fc:	93 e1 00 2c 	stw	r31,44(r1)
> 48040600:	90 01 00 34 	stw	r0,52(r1)
> 48040604:	7c 3f 0b 78 	mr	r31,r1
> 48040608:	90 7f 00 08 	stw	r3,8(r31)
> 4804060c:	90 9f 00 0c 	stw	r4,12(r31)
> 	unsigned int x = m_id;
> 48040610:	81 3f 00 08 	lwz	r9,8(r31)
> 48040614:	80 09 00 00 	lwz	r0,0(r9)
> 48040618:	90 1f 00 10 	stw	r0,16(r31)
> 	m_dir = value;
> 4804061c:	81 3f 00 08 	lwz	r9,8(r31)
> 48040620:	80 1f 00 0c 	lwz	r0,12(r31)
> 48040624:	90 09 00 04 	stw	r0,4(r9)
> 	Test* p = this;
> 48040628:	80 1f 00 08 	lwz	r0,8(r31)
> 4804062c:	90 1f 00 14 	stw	r0,20(r31)
> 	printf("This is me %u at 0x%p\n", x, p);
> 48040630:	3d 20 48 04 	lis	r9,18436
> 48040634:	38 69 07 c4 	addi	r3,r9,1988
> 48040638:	80 9f 00 10 	lwz	r4,16(r31)
> 4804063c:	80 bf 00 14 	lwz	r5,20(r31)
> 48040640:	4c c6 31 82 	crclr	4*cr1+eq
> 48040644:	48 00 12 f9 	bl	4804193c <_edata+0x4c>
> }
> 48040648:	81 61 00 00 	lwz	r11,0(r1)
> 4804064c:	80 0b 00 04 	lwz	r0,4(r11)
> 48040650:	7c 08 03 a6 	mtlr	r0
> 48040654:	83 eb ff fc 	lwz	r31,-4(r11)
> 48040658:	7d 61 5b 78 	mr	r1,r11
> 4804065c:	4e 80 00 20 	blr
> 
> Thanks
> robert
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25397
>