public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/113321] New: x86-64: Make __attribute__((interrupt)) more robust
@ 2024-01-11  1:44 hpa at zytor dot com
  2024-01-11  1:53 ` [Bug target/113321] " hjl.tools at gmail dot com
  2024-01-11  2:14 ` hpa at zytor dot com
  0 siblings, 2 replies; 3+ messages in thread
From: hpa at zytor dot com @ 2024-01-11  1:44 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 113321
           Summary: x86-64: Make __attribute__((interrupt)) more robust
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hpa at zytor dot com
  Target Milestone: ---

__attribute__((interrupt)) on x86 has two prototypes, and picking the wrong
type "probably will cause a system crash." It turns out that this is
unavoidable on i386, but on x86-64 we can do better:

- On x86-64, an exception/interrupt carries an error code if and only if the
stack is 16-byte aligned (specifically, RSP[3] = 0) on exception entry.

The proper stack pointer for using with IRET is therefore always given by:

RSP |= 8

... and the error code, if present, will be located at offset -8 from this
address.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug target/113321] x86-64: Make __attribute__((interrupt)) more robust
  2024-01-11  1:44 [Bug target/113321] New: x86-64: Make __attribute__((interrupt)) more robust hpa at zytor dot com
@ 2024-01-11  1:53 ` hjl.tools at gmail dot com
  2024-01-11  2:14 ` hpa at zytor dot com
  1 sibling, 0 replies; 3+ messages in thread
From: hjl.tools at gmail dot com @ 2024-01-11  1:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H. Peter Anvin from comment #0)
> __attribute__((interrupt)) on x86 has two prototypes, and picking the wrong
> type "probably will cause a system crash." It turns out that this is
> unavoidable on i386, but on x86-64 we can do better:
> 
> - On x86-64, an exception/interrupt carries an error code if and only if the
> stack is 16-byte aligned (specifically, RSP[3] = 0) on exception entry.
> 
> The proper stack pointer for using with IRET is therefore always given by:
> 
> RSP |= 8
> 
> ... and the error code, if present, will be located at offset -8 from this
> address.

GCC always generates IRET for __attribute__((interrupt)).  If there are 2
arguments (one of them is the error code), it is an exception handler.
Otherwise, it is an interrupt handler.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug target/113321] x86-64: Make __attribute__((interrupt)) more robust
  2024-01-11  1:44 [Bug target/113321] New: x86-64: Make __attribute__((interrupt)) more robust hpa at zytor dot com
  2024-01-11  1:53 ` [Bug target/113321] " hjl.tools at gmail dot com
@ 2024-01-11  2:14 ` hpa at zytor dot com
  1 sibling, 0 replies; 3+ messages in thread
From: hpa at zytor dot com @ 2024-01-11  2:14 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from H. Peter Anvin <hpa at zytor dot com> ---
Right. The only thing I'm suggesting is that for the cost of one extra
instruction we can make it robust against the programmer picking the wrong
type, or wanting to use the same handler.

It isn't a necessary thing by any means.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-01-11  2:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-11  1:44 [Bug target/113321] New: x86-64: Make __attribute__((interrupt)) more robust hpa at zytor dot com
2024-01-11  1:53 ` [Bug target/113321] " hjl.tools at gmail dot com
2024-01-11  2:14 ` hpa at zytor dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).