https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70220
--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> --- (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?
