[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

["hjl.tools at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(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.