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 19:19:45 -0400 Message-ID: <20140625231945.GF179@brightrain.aerifal.cx> References: <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> <20140625220758.GE179@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 1403738419 3815 80.91.229.3 (25 Jun 2014 23:20:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 23:20:19 +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 01:20:12 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 1WzwU6-0003YV-Hn for ged-emacs-devel@m.gmane.org; Thu, 26 Jun 2014 01:20:10 +0200 Original-Received: from localhost ([::1]:41517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzwU5-0005et-RV for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 19:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzwTx-0005aE-7C for emacs-devel@gnu.org; Wed, 25 Jun 2014 19:20:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzwTq-000265-Tp for emacs-devel@gnu.org; Wed, 25 Jun 2014 19:20:01 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:44451 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzwTk-000253-53; Wed, 25 Jun 2014 19:19:48 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1WzwTh-0005Sj-00; Wed, 25 Jun 2014 23:19:45 +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:172736 Archived-At: On Wed, Jun 25, 2014 at 07:05:14PM -0400, Stefan Monnier wrote: > >> - 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. > > The manual code would be fairly normal C code, very similar to the > mark_object routine. It shouldn't be noticeably less portable than the > current pointer<->int conversions we use for tagging purposes. > > Of course, it's always nice when we can use someone else's code, but > I get the impression that to get the right behavior from the > compiler/linker/loader we may have to generate a fairly enormous C file > which will generate an enormous .o file and the resulting binary will > end up with a humongous relocation table. For non-PIE emacs, the relocations would only exist in the .o file, which would only be "enormous" to the extent that the actual data is (IIRC roughly 11 megs for 32-bit and 16 megs for 64-bit). For PIE, the relocations are carried over to the executable, but they're all relative (not symbolic) and thus trivial from a performance standpoint. Rich