On 04/18/2014 11:31 PM, Richard Henderson wrote:
> On 04/17/2014 10:14 AM, DJ Delorie wrote:
>> _medium_frame:
>> pushm r6-r12
>> add #-4, r0, r6 ; marked frame-related (fp = sp - 4)
>> mov.L r6, r0
On 04/17/2014 10:14 AM, DJ Delorie wrote:
> _medium_frame:
> pushm r6-r12
> add #-4, r0, r6 ; marked frame-related (fp = sp - 4)
> mov.L r6, r0 ; marked frame-related (sp = fp)
There's your
> Also, is that rule true if we *don't* have a frame pointer? That is,
> when we add a constant to the stack to allocate the frame, should that
> function be marked as frame-related? Or is it just the fp->sp move
> (or potentially an add, if there's outgoing args) that shouldn't be
> marked?
The
> The "mov.L r6, r0" instruction must never be marked as frame-related, for any
> function.
Also, is that rule true if we *don't* have a frame pointer? That is,
when we add a constant to the stack to allocate the frame, should that
function be marked as frame-related? Or is it just the fp->sp
> The "mov.L r6, r0" instruction must never be marked as frame-related, for any
> function.
Is this documented somewhere?
> 0010 CIE
> Version: 3
> Augmentation: ""
> Code alignment factor: 1
> Data alignment factor: -4
> Return address column: 17
>
> DW_CFA_def_cfa: r0 ofs 4
> DW_CFA_offset: r17 at cfa-4
> DW_CFA_nop
> DW_CFA_nop
OK so r0 (sp) is the CF
> I gather that r0 is the stack pointer and r6 the frame pointer?
Yes.
> > 0014 0030 FDE cie= pc=..0043
> > DW_CFA_advance_loc4: 2 to 0002
> > DW_CFA_def_cfa_offset: 32
> > DW_CFA_offset: r12 at cfa-8
> > . . .
> > DW_CFA_offset: r6 at cfa-32
>
> The last stack adjustment it sees is
> the rx backend's adjustment to allocate the frame:
>
> _medium_frame:
> pushm r6-r12
> add #-4, r0, r6 ; marked frame-related (fp = sp -
> 4) mov.L r6, r0 ; marked frame-related (sp = fp) . .
> .
On Thu, Apr 17, 2014 at 10:14 AM, DJ Delorie wrote:
>
> The rx back-end doesn't define TARGET_FRAME_POINTER_REQUIRED, as the
> documentation says the compiler handles target-independent reasons why
> there needs to be a frame pointer. But, the default
> TARGET_FRAME_POINTER_REQUIRED just returns
> Presumably the rx back-end and more precisely TARGET_FRAME_POINTER_REQUIRED,
> which needs to return true if cfun->calls_alloca.
The rx back-end doesn't define TARGET_FRAME_POINTER_REQUIRED, as the
documentation says the compiler handles target-independent reasons why
there needs to be a frame
> While debugging some gdb-related FAILs, I discovered that gcc's
> -fstack-check option effectively calls alloca() to adjust the stack
> pointer.
Note that the subject is misleading, -fstack-check is stack checking and not
stack protection, which is -fstack-protector.
> However, it doesn't mark
While debugging some gdb-related FAILs, I discovered that gcc's
-fstack-check option effectively calls alloca() to adjust the stack
pointer.
However, it doesn't mark the stack adjustment as FRAME_RELATED even
when it's setting up the local variables for the function.
In the case of rx-elf, for t
12 matches
Mail list logo
