GNU bug report logs -
#46965
28.0.50; unexec does not build (or work)
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Sat, 6 Mar 2021 14:03:01 UTC
Severity: normal
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46965 in the body.
You can then email your comments to 46965 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46965
; Package
emacs
.
(Sat, 06 Mar 2021 14:03:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pip Cet <pipcet <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 06 Mar 2021 14:03:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
On this Debian-based x86_64-pc-linux-gnu system, configuring with
--with-dumping=unexec results in various errors:
1. a compilation error in pdumper.c. Easy to fix, my fault, but then there's ...
2. a segfault when running the dumped image. The problem is we can't
use glibc's malloc when running a dumped image, so we need to force
use of hybrid malloc. But then...
3. gnulib no longer builds with hybrid malloc. To do so requires some
massaging of the gnulib files, but then...
4. gnulib redirects free() to always point to the glibc free(), even
when Emacs wants to override it for hybrid malloc. To fix this, we
need to rerun gnulib-tool.
(1) tells me it's very unlikely anyone but me has tried to build
unexec Emacs lately. The other bugs tell me that it's getting rapidly
more difficult to support unexec build.
But unexec does provide performance advantages over pdumper, and even
over undumped builds.
So, do we want to keep it as an option? RMS said so in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36649;msg=77
So I'm opening this bug for discussion, and to post the patches I need
to make unexec work again.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46965
; Package
emacs
.
(Sat, 06 Mar 2021 19:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 46965 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 6, 2021 at 2:03 PM Pip Cet <pipcet <at> gmail.com> wrote:
> But unexec does provide performance advantages over pdumper, and even
> over undumped builds.
That, by the way, is because of pure space.
Here's the patch to make unexec build. Note that this patch removes
the free() wrapper from lib/, so if your libc's free() is broken and
sets errno, that bug will be once again exposed.
[0001-fix-build-with-dumping-unexec.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46965
; Package
emacs
.
(Sat, 06 Mar 2021 20:05:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 46965 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 6 Mar 2021 19:07:02 +0000
>
> Here's the patch to make unexec build. Note that this patch removes
> the free() wrapper from lib/, so if your libc's free() is broken and
> sets errno, that bug will be once again exposed.
Hmm... why do we need to add so much stuff from Gnulib?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46965
; Package
emacs
.
(Sat, 06 Mar 2021 20:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 46965 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 6, 2021 at 8:04 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sat, 6 Mar 2021 19:07:02 +0000
> > Here's the patch to make unexec build. Note that this patch removes
> > the free() wrapper from lib/, so if your libc's free() is broken and
> > sets errno, that bug will be once again exposed.
>
> Hmm... why do we need to add so much stuff from Gnulib?
We don't, I hope, but I don't know how to properly regenerate the
gnulib dependencies :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46965
; Package
emacs
.
(Mon, 20 Jun 2022 01:28:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 46965 <at> debbugs.gnu.org (full text, mbox):
Pip Cet <pipcet <at> gmail.com> writes:
> On this Debian-based x86_64-pc-linux-gnu system, configuring with
> --with-dumping=unexec results in various errors:
>
> 1. a compilation error in pdumper.c. Easy to fix, my fault, but then there's ...
> 2. a segfault when running the dumped image. The problem is we can't
> use glibc's malloc when running a dumped image, so we need to force
> use of hybrid malloc. But then...
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
It looks like this was fixed in:
commit 44ed8f6555288f00b982f21e68ac5a51372279de
Author: Eli Zaretskii <eliz <at> gnu.org>
AuthorDate: Sun Apr 4 10:10:00 2021 +0300
And the unexec build seems to work OK for me still, so I'm closing this
bug report. (If there's more to be done here, please respond to the
debbugs address and we'll reopen.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
46965 <at> debbugs.gnu.org and Pip Cet <pipcet <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 20 Jun 2022 01:28:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 18 Jul 2022 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 281 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.