https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70220

--- Comment #11 from Wink Saville <wink at saville dot com> ---
(In reply to H.J. Lu from comment #10)
> (In reply to Wink Saville from comment #9)
> > (In reply to H.J. Lu from comment #8)
> > > (In reply to Wink Saville from comment #7)
> > > >
> > > > In my opinion, even if rbp is special, it still needs to be available 
> > > > in the
> > > > struct full_stack_frame.
> > > 
> > > The whole idea of extending interrupter attribute is to avoid
> > > full_stack_frame.
> > > ISR shouldn't assume that compiler will save and restore registers in any
> > > specific way, order or form.  As far as ISR is concerned, it is just black
> > > magic.
> > 
> > From my perspective the goal is not to avoid struct full_stack_frame but to
> > allow it to be created and always consistent.
> 
> Compiler is free to do whatever is the best.  You shouldn't assume anything
> from compiler beyond the interrupt attribute spec.  If you insist that
> compiler must save registers in certain way, interrupt attribute isn't
> appropriate for your use case.
> 
> > > 
> > > > Also, isn't rsp special? Would the compiler or programmer be 
> > > > responsible for
> > > > initializing it. It seems to me it has to be the compiler, but could be
> > > > wrong.
> > > 
> > > If you change rsp in asm statement, you have to restore it in asm 
> > > statement.
> > 
> > The rsp is always saved/restored by the hardware, and your struct frame
> > pointer provides access to it so no problem there. It is special because
> > when there are local variables the compiler needs to modify it and currently
> > it does that after the registers are saved. How will we coordinate the
> > compiler initializing rsp and the programming saving the registers?
> 
> Why is it a problem if IRS doesn't assume what/how compiler does?

I'm in total agreement, the programmer cannot assume anything and must rely on
what the interrupt attribute specification says.

At the moment the technique for saving the registers using mov's instead of
push/pop's looks to resolve a possible problem of the programmer manipulating
rsp. So the only problem seems to be how make rbp accessible because its
special. I suggest the interrupt attribute specification say something along
the lines of:

"The interrupt attribute takes optional parameters. The parameters are a list
of registers that the compiler will NOT save and it will be the responsibility
of the programmer to save them. As a convenience to the programmer a single
"all" parameter maybe used instead of a specific list. The only register not
allowed is RBP as its reserved for use by the compiler.

If there is a list of registers to not save then original value of rbp will be
saved to RAM and rbp will be set to its location."

Reply via email to