https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70220
--- Comment #13 from Wink Saville <wink at saville dot com> --- (In reply to H.J. Lu from comment #12) > (In reply to Wink Saville from comment #11) > > > > 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. > > So far so good. > > > 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." > > Compiler should be free to use rbp in anyway it sees fit. Spec shouldn't > say anything other than rbp is special to compiler. If the compiler does decide to change rbp it must save original value, correct?
