GNU bug report logs - #36649
27.0.50; pure space and pdumper

Previous Next

Full log

Message #217 received at 36649 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
 schwab <at> linux-m68k.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 36649 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#36649: 27.0.50; pure space and pdumper
Date: Thu, 13 May 2021 14:44:03 +0000

On Wed, May 12, 2021 at 7:44 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I don't know if this is an interesting configuration.  AFAIU,
> > "--with-dumping=none" means you run the CANNOT_DUMP version, which
> > doesn't dump Emacs at all.
>
> Ah, yes...  and in that case I guess there is no pure space?  Oh well, I
> guess somebody has to look into getting unexec working on Linux if we're
> to, er, see what the impact of pure space unexec would have been.  If it
> was working.  :-)

I had it working a while ago, just not using libc malloc(). AFAIU,
that's just incompatible with unexec() now.

(And it's still slightly but significantly faster building with
unexec() on Linux than building with pdumper, at least in contrived
benchmarks).

So, yes, I'd misunderstood Eli and thought he had objections to this
patch; if he doesn't, we should look into fixing the native-comp parts
and apply it :-)

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.