emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs port to gcc -fcheck-pointer-bounds


From: Paul Eggert
Subject: Re: Emacs port to gcc -fcheck-pointer-bounds
Date: Fri, 8 Dec 2017 14:06:25 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]