The direction of malloc?

[Mike Frysinger]

On Tuesday 10 December 2013 13:04:04 Joseph S. Myers wrote:
> On Tue, 10 Dec 2013, Will Newton wrote:
> > > One significant difficulty with building a replacement into glibc is
> > > supporting malloc_set_state calls with data saved with a previous glibc
> > > version - the problem that has so far prevented us from correcting
> > > malloc alignment for powerpc32 without breaking emacs (bug 6527 - as
> > > noted in that bug, it should be fixed for 32-bit x86 as well to
> > > support ISO C extensions such as _Decimal128 properly, if a way to fix
> > > it is found).
> > 
> > Is that actually possible? I thought malloc_get_state just returned an
> > opaque pointer so I wasn't aware it could be written out to any kind
> > of storage or last longer than the lifetime of a process.
> 
> The main purpose of malloc_get_state / malloc_set_state is for use by
> emacs.  If emacs adopted a better approach I'd happily deprecate them -
> turn them into compat symbols - but you still need to support them
> indefinitely with existing emacs binaries, as a matter of binary
> compatibility.  (Support could mean such binaries - binaries using the
> malloc_set_state compat symbol - use a different copy of malloc in libc
> from what all other binaries use, if necessary.)

does emacs need it for every process invocation, or just for the initial weird 
dump logic ?  i'm guessing the former so that it can support the latter ...

we could even relegate that alternate allocator to a runtime dlopen so we 
don't have to have it always linked in.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20131216/43ba72c4/attachment.sig>