Oddities in ARM (stack handling)

Oddities in ARM (stack handling)

[Adrian von Bidder]

Hi!

While debugging my membedded-pic (formerly disable-got by Vlad Lebedev)
patch I discovered that my patch also influences code generation with my
flag disabled. Damn.

To find out where to start: with patch, a function compiles with
frame_needed = 0, 3.0.2 vanilla compiles the function to frame_neede =
1.

So I wonder what influences the decision whether a given function needs
a frame pointer (the only point where frame_pointer_needed is set seems
to be in reload1.c, and I don't understand the explanation there. Also I
did not change that file).

Additionally - and this is the odditiy I'm speaking of in the subject -
the unchainged functions saves the registers with "stmfd {
everything..., pc }".

I wonder why to save the pc - it is never loaded, nor is the space
reserved on the stack ever needed.
 
greets from Zürich
-- vbi

Re: Oddities in ARM (stack handling)

[Nick Clifton]

Hi Adrian,

> So I wonder what influences the decision whether a given function
> needs a frame pointer (the only point where frame_pointer_needed is
> set seems to be in reload1.c, and I don't understand the explanation
> there. Also I did not change that file).

The macro FRAME_POINTER_REQUIRED is also relevant.  (see arm.h)
 
> Additionally - and this is the odditiy I'm speaking of in the
> subject - the unchainged functions saves the registers with "stmfd { 
> everything..., pc }".
> 
> I wonder why to save the pc - it is never loaded, nor is the space
> reserved on the stack ever needed.

Because it creates a stack frame, as per the ARM Procedure Call
Standard.  The APCS says that frames are optional, so if the frame
pointer is not needed the stack frame is not created, but if the frame
pointer is needed then the code creates a valid stack frame.

Cheers
        Nick

Oddities in ARM (stack handling)

[Adrian von Bidder]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Hi!

While debugging my membedded-pic (formerly disable-got by Vlad Lebedev)
patch I discovered that my patch also influences code generation with my
flag disabled. Damn.

To find out where to start: with patch, a function compiles with
frame_needed = 0, 3.0.2 vanilla compiles the function to frame_neede =
1.

So I wonder what influences the decision whether a given function needs
a frame pointer (the only point where frame_pointer_needed is set seems
to be in reload1.c, and I don't understand the explanation there. Also I
did not change that file).

Additionally - and this is the odditiy I'm speaking of in the subject -
the unchainged functions saves the registers with "stmfd {
everything..., pc }".

I wonder why to save the pc - it is never loaded, nor is the space
reserved on the stack ever needed.
 
greets from Zürich
-- vbi

Re: Oddities in ARM (stack handling)

[Nick Clifton]

Hi Adrian,

> So I wonder what influences the decision whether a given function
> needs a frame pointer (the only point where frame_pointer_needed is
> set seems to be in reload1.c, and I don't understand the explanation
> there. Also I did not change that file).

The macro FRAME_POINTER_REQUIRED is also relevant.  (see arm.h)
 
> Additionally - and this is the odditiy I'm speaking of in the
> subject - the unchainged functions saves the registers with "stmfd { 
> everything..., pc }".
> 
> I wonder why to save the pc - it is never loaded, nor is the space
> reserved on the stack ever needed.

Because it creates a stack frame, as per the ARM Procedure Call
Standard.  The APCS says that frames are optional, so if the frame
pointer is not needed the stack frame is not created, but if the frame
pointer is needed then the code creates a valid stack frame.

Cheers
        Nick