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

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Pip Cet <pipcet <at> gmail.com>
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, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#36649: 27.0.50; pure space and pdumper
Date: Thu, 13 May 2021 21:23:10 +0000

Pip Cet <pipcet <at> gmail.com> writes:

> 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 :-)

Right, if you like me to have a look to the native-comp side would be
handy to have this patch pushed as a git branch on our repo.

  Andrea

Previous Next

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