About "STARTING_FRAME_OFFSET" definition

About "STARTING_FRAME_OFFSET" definition

[redriver jiang]

Hi all,

Can this "STARTING_FRAME_OFFSET" macro be defined to be a non-constant
value ( changes with the "current_function_args_size")?

As the target process has "FP+offset" with postive "offset"( stack
grows upward, and parameters in stack grows downward), for example,

call foo( arg1, arg2, arg3,arg4), after foo's prologue, the stack is like this:

                                             <---- low address
         |--------------------------------|
	 |     Incoming arg4       | <-------------FP
         |--------------------------------|
	 |      Incoming arg3      |
         |--------------------------------|
	 |     Incoming arg2       |
	 |--------------------------------|
	 |     Incoming arg1       | <---------------ARG
	 |--------------------------------|
	 |	return PC of foo   |
	 |--------------------------------|
	 |		saved regs  |
	 |--------------------------------|
	 |		old FP        |
	 |--------------------------------|
	 |         local var0         |
	 |--------------------------------|
			                    <---- high address

 "STARTING_FRAME_OFFSET" means the offset between FP and the first
local variable, in this situation,

STARTING_FRAME_OFFSE = current_function_args_size+ size(PC in stack) +
size(saved regs) + size(old FP).

so, "STARTING_FRAME_OFFSET" depends on the
"current_function_args_size", which is a GCC internal variable.

Is this stack layout suitable?

Thanks!

redriver

Re: About "STARTING_FRAME_OFFSET" definition

[Richard Henderson]

On 03/23/2010 05:55 AM, redriver jiang wrote:
> Hi all,
> 
> Can this "STARTING_FRAME_OFFSET" macro be defined to be a non-constant
> value ( changes with the "current_function_args_size")?
> 
> As the target process has "FP+offset" with postive "offset"( stack
> grows upward, and parameters in stack grows downward), for example,
> 
> call foo( arg1, arg2, arg3,arg4), after foo's prologue, the stack is like this:
> 
>                                              <---- low address
>          |--------------------------------|
> 	 |     Incoming arg4       | <-------------FP
>          |--------------------------------|
> 	 |      Incoming arg3      |
>          |--------------------------------|
> 	 |     Incoming arg2       |
> 	 |--------------------------------|
> 	 |     Incoming arg1       | <---------------ARG
> 	 |--------------------------------|
> 	 |	return PC of foo   |
> 	 |--------------------------------|
> 	 |		saved regs  |
> 	 |--------------------------------|
> 	 |		old FP        |
> 	 |--------------------------------|
> 	 |         local var0         |
> 	 |--------------------------------|
> 			                    <---- high address
> 
>  "STARTING_FRAME_OFFSET" means the offset between FP and the first
> local variable, in this situation,
> 
> STARTING_FRAME_OFFSE = current_function_args_size+ size(PC in stack) +
> size(saved regs) + size(old FP).
> 
> so, "STARTING_FRAME_OFFSET" depends on the
> "current_function_args_size", which is a GCC internal variable.
> 
> Is this stack layout suitable?

It's possible to create this stack layout, yes.

STARTING_FRAME_OFFSET doesn't really ought not enter into it, I don't think.

What you'll want instead is to have a separate "soft" frame_pointer_rtx
and hard_frame_pointer_rtx.  Then during register allocation you eliminate
from the soft frame pointer to the hard frame pointer with an offset you
calculate at that point.  There are many examples of this in existing ports,
including the i386 port.

The reason why you want to handle this via elimination rather than a fixed
offset during initial rtl generation is your "saved regs" field there, which
of course will vary in size depending on what registers get spilled.

So I would begin with STARTING_FRAME_OFFSET=0 and have the soft frame pointer
point to "local var0" in your picture.  Then your INITIAL_ELIMINATION_OFFSET
function would map:

  ARG_POINTER_REGNUM	HARD_FRAME_POINTER_REGNUM
  = -current_function_args_size

  FRAME_POINTER_REGNUM	HARD_FRAME_POINTER_REGNUM
  = -(sizeof(saved_regs) + sizeof(FP) + sizeof(return PC) + current_function_args_size)



r~

Re: About "STARTING_FRAME_OFFSET" definition

[redriver jiang]

Hi,

Thanks!
I  also find the doc describing the "HARD_FRAME_POINTER_REGNUM" and

"FRAME_POINTER_REGNUM" in "gcc internals", chapter "Registers That
Address the Stack Frame".

It is really "usual" way to handle this similar cases.

redriver


2010/3/24 Richard Henderson <rth@redhat.com>:
> On 03/23/2010 05:55 AM, redriver jiang wrote:
>> Hi all,
>>
>> Can this "STARTING_FRAME_OFFSET" macro be defined to be a non-constant
>> value ( changes with the "current_function_args_size")?
>>
>> As the target process has "FP+offset" with postive "offset"( stack
>> grows upward, and parameters in stack grows downward), for example,
>>
>> call foo( arg1, arg2, arg3,arg4), after foo's prologue, the stack is like this:
>>
>>                                              <---- low address
>>          |--------------------------------|
>>        |     Incoming arg4       | <-------------FP
>>          |--------------------------------|
>>        |      Incoming arg3      |
>>          |--------------------------------|
>>        |     Incoming arg2       |
>>        |--------------------------------|
>>        |     Incoming arg1       | <---------------ARG
>>        |--------------------------------|
>>        |      return PC of foo   |
>>        |--------------------------------|
>>        |              saved regs  |
>>        |--------------------------------|
>>        |              old FP        |
>>        |--------------------------------|
>>        |         local var0         |
>>        |--------------------------------|
>>                                           <---- high address
>>
>>  "STARTING_FRAME_OFFSET" means the offset between FP and the first
>> local variable, in this situation,
>>
>> STARTING_FRAME_OFFSE = current_function_args_size+ size(PC in stack) +
>> size(saved regs) + size(old FP).
>>
>> so, "STARTING_FRAME_OFFSET" depends on the
>> "current_function_args_size", which is a GCC internal variable.
>>
>> Is this stack layout suitable?
>
> It's possible to create this stack layout, yes.
>
> STARTING_FRAME_OFFSET doesn't really ought not enter into it, I don't think.
>
> What you'll want instead is to have a separate "soft" frame_pointer_rtx
> and hard_frame_pointer_rtx.  Then during register allocation you eliminate
> from the soft frame pointer to the hard frame pointer with an offset you
> calculate at that point.  There are many examples of this in existing ports,
> including the i386 port.
>
> The reason why you want to handle this via elimination rather than a fixed
> offset during initial rtl generation is your "saved regs" field there, which
> of course will vary in size depending on what registers get spilled.
>
> So I would begin with STARTING_FRAME_OFFSET=0 and have the soft frame pointer
> point to "local var0" in your picture.  Then your INITIAL_ELIMINATION_OFFSET
> function would map:
>
>  ARG_POINTER_REGNUM    HARD_FRAME_POINTER_REGNUM
>  = -current_function_args_size
>
>  FRAME_POINTER_REGNUM  HARD_FRAME_POINTER_REGNUM
>  = -(sizeof(saved_regs) + sizeof(FP) + sizeof(return PC) + current_function_args_size)
>
>
>
> r~
>