This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |