all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: Daniel Colascione <dancol@dancol.org>
Cc: Wolfgang Jenkner <wjenkner@inode.at>,
	22086@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc patch for elf systems
Date: Mon, 21 Dec 2015 15:49:13 -0500	[thread overview]
Message-ID: <20151221204913.GY238@brightrain.aerifal.cx> (raw)
In-Reply-To: <56785C4E.1060202@dancol.org>

On Mon, Dec 21, 2015 at 12:08:46PM -0800, Daniel Colascione wrote:
> On 12/20/2015 08:06 PM, Rich Felker wrote:
> > On Sun, Dec 20, 2015 at 10:37:24PM -0500, Ken Brown wrote:
> >> On 12/20/2015 5:33 PM, Paul Eggert wrote:
> >>> While thinking over this patch I'd like to propose what should be a
> >>> simpler approach. This new proposal is more radical, and so should not
> >>> be applied to the emacs-25 branch, but it should make the port to musl
> >>> etc. automatic.
> >>>
> >>> The simpler approach is to remove gmalloc.c, and to use the system
> >>> memory allocator, i.e., to behave as if SYSTEM_MALLOC is defined on all
> >>> platforms.
> >>>
> >>> We can still support hybrid malloc for Cygwin, if SYSTEM_MALLOC wouldn't
> >>> work on Cygwin for some reason; and we can support the similar hybrid on
> >>> Darwin, if it's still needed.
> >>
> >> SYSTEM_MALLOC doesn't work on Cygwin, largely because Cygwin's
> >> malloc doesn't support malloc_set_state and malloc_get_state.  There
> >> may be other problems too.  (It's been a while since I tried it.)
> > 
> > I don't see how this is possible; malloc_[gs]et_state do not exist on
> > other systems either. Presumably this is some hack needed for the
> > dumper, which wouldn't be needed if malloc weren't used pre-dumping.
> 
> We really shouldn't be dumping the native heap at all, really.
> Eventually, Emacs should be a position-independent executable (as should
> every other program), and to unexec a PIE, we need to emit relocations,
> and to emit relocations, we need to know where all the pointers are. We
> can't do that if the internal heap structure is opaque to us.

Actually you can, because the internal heap structure is not what you
need to dump. The "lisp heap" is what you need to dump, and it's
walkable in the same way you walk it now for garbage collection
purposes. It should be possible to adapt the GC code into a dumper
that dumps only the lisp data (with relocations in a form emacs can
internally process, i.e. not relying on writing a new executable
binary with ELF-level or other system-specific relocs) and no unwanted
additional state; then, even static linking should work correctly.

Rich





  reply	other threads:[~2015-12-21 20:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 17:57 bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc patch for elf systems Wolfgang Jenkner
2015-12-16  8:28 ` Paul Eggert
2015-12-16 17:15   ` Rich Felker
2015-12-16 17:47     ` Eli Zaretskii
2015-12-17 13:16   ` Wolfgang Jenkner
2015-12-17 16:17     ` Eli Zaretskii
2015-12-17 16:26     ` Rich Felker
2015-12-18  0:06       ` Wolfgang Jenkner
2015-12-18  6:57         ` Eli Zaretskii
2015-12-18 13:15           ` Wolfgang Jenkner
2015-12-18 14:38             ` Eli Zaretskii
2015-12-20 22:33     ` Paul Eggert
2015-12-21  1:59       ` Rich Felker
2015-12-21  2:37         ` Paul Eggert
2015-12-21  2:51           ` Rich Felker
2015-12-21 11:10             ` Paul Eggert
2015-12-21 18:01               ` Rich Felker
2015-12-23  8:24                 ` Paul Eggert
2015-12-21  3:37       ` Ken Brown
2015-12-21  4:06         ` Rich Felker
2015-12-21 12:24           ` Ken Brown
2015-12-21 20:08           ` Daniel Colascione
2015-12-21 20:49             ` Rich Felker [this message]
2015-12-21 20:58               ` Daniel Colascione
2015-12-21  3:44       ` Eli Zaretskii
2015-12-21 11:18         ` Paul Eggert
2015-12-21 15:37           ` Eli Zaretskii
2015-12-21 17:11             ` Paul Eggert
2015-12-21 15:14       ` Wolfgang Jenkner
2015-12-21 15:46         ` Wolfgang Jenkner
2015-12-21 17:06         ` Paul Eggert
2015-12-21 17:28           ` Wolfgang Jenkner
2015-12-23  8:31             ` Paul Eggert
2016-01-30  9:17 ` bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid mallo Paul Eggert
2016-01-30  9:40   ` Eli Zaretskii
2016-01-31  0:43     ` Paul Eggert
2016-01-31 16:51       ` Wolfgang Jenkner
2016-01-31 17:54         ` Paul Eggert
2016-01-31  0:53   ` Rich Felker
2016-02-01 15:15 ` Wolfgang Jenkner
2016-02-01 16:58   ` Paul Eggert
2016-02-01 18:34     ` Wolfgang Jenkner
2016-02-01 19:38       ` Eli Zaretskii
2016-02-01 23:08         ` Paul Eggert
2016-02-09 14:55 ` Wolfgang Jenkner
2016-02-09 23:31 ` Paul Eggert
2016-02-10 12:27   ` Wolfgang Jenkner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151221204913.GY238@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=22086@debbugs.gnu.org \
    --cc=dancol@dancol.org \
    --cc=eggert@cs.ucla.edu \
    --cc=wjenkner@inode.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.