From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Emacs port to gcc -fcheck-pointer-bounds Date: Fri, 8 Dec 2017 14:06:25 -0800 Organization: UCLA Computer Science Department Message-ID: References: <83indhwcx5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512770796 17187 195.159.176.226 (8 Dec 2017 22:06:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 8 Dec 2017 22:06:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: pipcet@gmail.com, Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 08 23:06:33 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNQmu-0004MN-0g for ged-emacs-devel@m.gmane.org; Fri, 08 Dec 2017 23:06:32 +0100 Original-Received: from localhost ([::1]:39220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNQn1-0000Ra-8N for ged-emacs-devel@m.gmane.org; Fri, 08 Dec 2017 17:06:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNQmu-0000RD-Qc for Emacs-devel@gnu.org; Fri, 08 Dec 2017 17:06:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNQmq-0000Wx-SQ for Emacs-devel@gnu.org; Fri, 08 Dec 2017 17:06:32 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47030) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eNQmq-0000WA-Lh; Fri, 08 Dec 2017 17:06:28 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DA701161382; Fri, 8 Dec 2017 14:06:26 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id eOOZjM7uGQiZ; Fri, 8 Dec 2017 14:06:26 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1469E161383; Fri, 8 Dec 2017 14:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R4ZlgGc-a6Vg; Fri, 8 Dec 2017 14:06:25 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id EC960161248; Fri, 8 Dec 2017 14:06:25 -0800 (PST) In-Reply-To: <83indhwcx5.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220803 Archived-At: 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.