From: "H. Peter Anvin" <hpa@zytor.com>
To: Albert Cahalan <acahalan@gmail.com>
Cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
76306.1226@compuserve.com, ak@muc.de, akpm@osdl.org
Subject: Re: i386 ABI and the stack
Date: Fri, 23 Jun 2006 18:50:11 -0700 [thread overview]
Message-ID: <449C9A53.7040204@zytor.com> (raw)
In-Reply-To: <787b0d920606231837k5d57da8ct5c511def6c035176@mail.gmail.com>
Albert Cahalan wrote:
> I just saw git commit 21528454f6dd18231ae20102f98aa8f51b6ec1b9
> go in with this:
>
> + * Accessing the stack below %esp is always a bug.
> + * The large cushion allows instructions like enter
> + * and pusha to work. ("enter $65535,$31" pushes
> + * 32 pointers and then decrements %esp by 65535.)
>
> Exactly how is an access below %esp a bug if we just added support?
> It looks like we now have a 65664-byte red zone on i386, and probably
> on x86-64 once the matching patch goes in. (the space reserved by
> signal handlers may differ, though perhaps it should not)
No, we don't. The enter instruction is special because it *atomically*
drops the stack and probes the stack pointer; if the instruction fails,
then the stack pointer is rolled back, which is why the kernel needs to
be aware of it.
We could add a redzone to i386 (and then get compilers to know about
it), but we haven't already done so. The difference is that we'd have
to adjust the stack pointer before writing a signal stack frame.
However, libc probably needs to be aware of this, because this zone
needs to also be reserved for every stack in a threaded program.
> This is water under the bridge anyway, because of gcc 2.xx.x bugs.
>
> It seems that we're throwing away performance if we discourage
> the compiler from taking advantage of this area to optimize
> leaf functions and perhaps improve instruction scheduling.
Probably, although likely not much; x86 processors tend to need to
optimize push/pop anyway. However, as x86-64 shows, having a small
redzone might be worth it.
-hpa
prev parent reply other threads:[~2006-06-24 1:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-24 1:37 i386 ABI and the stack Albert Cahalan
2006-06-24 1:47 ` Linus Torvalds
2006-06-24 1:59 ` H. Peter Anvin
2006-06-24 2:11 ` Linus Torvalds
2006-06-24 2:43 ` Albert Cahalan
2006-06-24 5:20 ` H. Peter Anvin
2006-06-24 11:03 ` Arjan van de Ven
2006-06-24 1:50 ` H. Peter Anvin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=449C9A53.7040204@zytor.com \
--to=hpa@zytor.com \
--cc=76306.1226@compuserve.com \
--cc=acahalan@gmail.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.