From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pipcet@gmail.com, Emacs-devel@gnu.org
Subject: Re: Emacs port to gcc -fcheck-pointer-bounds
Date: Fri, 8 Dec 2017 14:06:25 -0800 [thread overview]
Message-ID: <a93b2c16-1fa0-d966-5e39-eaa13f9d005c@cs.ucla.edu> (raw)
In-Reply-To: <83indhwcx5.fsf@gnu.org>
On 12/08/2017 05:45 AM, Eli Zaretskii wrote:
> It's a large patch, so I think the discussion could benefit from an
> overview of the main points of the implementation.
>
> In particular, how would this work in a build --with-wide-int?
The short answer is, "It doesn't"; this is enforced by an '# error
"pointer-checking not supported with wide integers"' in src/lisp.h. The
longer answer is that I could add support for it, but I doubt whether
it's worth the trouble.
The basic idea of -fcheck-pointer-bounds is that you cannot lie to GCC
that a pointer is an integer: if a value is intended to be a pointer you
must declare it to be a pointer. You are allowed to calculate an
out-of-range pointer so long as you don't use it, and you are allowed to
cast it to some other type or to void *. The hardware/software
combination checks the bounds some (but not all, alas) pointer
dereferencing operations. The idea is to catch the most common cases
that might be victimized.
The -mmpx implementation does not change the size of pointers: they are
still 8 bytes on x86-64 and are still 4 bytes on x86. Instead, the
hardware keeps a cache that maps addresses of pointers to the pointers'
bounds. The compiler generates code that deduces a pointer's bounds from
the cache when the program loads a pointer from memory. It's the
compiler's responsibility to keep track of the bounds of pointers that
it keeps in registers, so that when it stores these pointers the cache
can be updated. The reason for all this complexity is to support
programs where only some modules have been built with
-fcheck-pointer-bounds, and where pointers are passed back and forth
between modules.
The -mmpx implementation is jury-rigged, and I do not recommend it for
production: it is so slow and buggy that not a lot of people use it, and
quite possibly it will be withdrawn from GCC some day. However, for
debugging Emacs it is useful and I found a real bug in emacs-26 with it.
Unlike -fsanitize=address, -fcheck-pointer-bounds works with a dumped
Emacs. (Well, it works halfway: since the cache doesn't survive
undumping, the dumped Emacs cannot check pointers created before Emacs
was dumped.) In contrast, -fsanitize=address makes a dumped Emacs crash
immediately.
next prev parent reply other threads:[~2017-12-08 22:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 7:34 Emacs port to gcc -fcheck-pointer-bounds Paul Eggert
2017-12-08 13:45 ` Eli Zaretskii
2017-12-08 22:06 ` Paul Eggert [this message]
2017-12-09 8:33 ` Eli Zaretskii
2017-12-10 7:10 ` Paul Eggert
2017-12-10 17:27 ` Eli Zaretskii
2017-12-11 7:54 ` Paul Eggert
2017-12-11 15:26 ` Eli Zaretskii
2017-12-12 23:35 ` Paul Eggert
2017-12-13 16:20 ` Eli Zaretskii
2017-12-13 18:30 ` Paul Eggert
2017-12-13 19:17 ` Stefan Monnier
2017-12-13 19:39 ` Paul Eggert
2017-12-18 2:47 ` Paul Eggert
2017-12-08 16:13 ` Pip Cet
2017-12-08 22:09 ` Paul Eggert
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=a93b2c16-1fa0-d966-5e39-eaa13f9d005c@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=Emacs-devel@gnu.org \
--cc=eliz@gnu.org \
--cc=pipcet@gmail.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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.