From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 18:07:58 -0400 Message-ID: <20140625220758.GE179@brightrain.aerifal.cx> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <831tucrguf.fsf@gnu.org> <20140625183241.GW179@brightrain.aerifal.cx> <83wqc4q0xl.fsf@gnu.org> <20140625190333.GZ179@brightrain.aerifal.cx> <20140625202403.GB179@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403734110 19593 80.91.229.3 (25 Jun 2014 22:08:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 22:08:30 +0000 (UTC) Cc: Eli Zaretskii , dmantipov@yandex.ru, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 26 00:08:23 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WzvMc-00039C-72 for ged-emacs-devel@m.gmane.org; Thu, 26 Jun 2014 00:08:22 +0200 Original-Received: from localhost ([::1]:41194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzvMb-0005mg-KY for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 18:08:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzvMU-0005mW-2V for emacs-devel@gnu.org; Wed, 25 Jun 2014 18:08:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzvMN-000394-Mq for emacs-devel@gnu.org; Wed, 25 Jun 2014 18:08:14 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:44448 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzvMH-00036N-0s; Wed, 25 Jun 2014 18:08:01 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1WzvME-0005M3-00; Wed, 25 Jun 2014 22:07:58 +0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172732 Archived-At: On Wed, Jun 25, 2014 at 05:43:00PM -0400, Stefan Monnier wrote: > > With the approach of dumping a C array containing references to > > offsets within itself, this is completely transparent to the > > application. The linker (ld) produces the right R_${ARCH}_RELATIVE > > relocation records in the data segment and the dynamic linker applies > > them at runtime. > > Two problems, here: > - we're still talking about performing relocation of all heap references > during startup (not that it's a problem, of course). Maybe we don't > need to do it ourselves, but it still has to happen. Indeed. The difference is just between having to write non-portable code that does it manually, and having it happen automatically as consequences of the requirements of the C language. > - Can the ld.so loader generate the *tagged* references used in the heap? My understanding is that the tagged references are using the low bits of otherwise-aligned pointers as flags. Is this correct? If so, then these are just constant offsets applied to an address, and thus they are still valid C address constant expressions, so they have to be supported. My understanding is that emacs also supports a mode for targets where alignment up to 8 bytes cannot be guaranteed, where the high bits of the pointer are used rather than the low bits, and where all pointers are required to reside in "low addresses". This should also be able to be supported at the dynamic-linker level as an addend. But at the C source level, it's undefined behavior since the offsets go outside the range of the array object. Of course this model is also incompatible with PIE and with most modern systems where malloc may return "high" addresses, and thereby likely buggy even on the systems it's currently used on (if any). It could probably be fixed by using mmap to ensure that the entire "high" memory space is filled with PROT_NONE mappings before doing anything else, though, but I think fixing this build mode is low priority since, in practice, all modern targets support 8-byte alignment. Rich