[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid mallo

From: Wolfgang Jenkner
Subject: bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid mallo
Date: Wed, 10 Feb 2016 13:27:37 +0100
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (berkeley-unix)

On Tue, Feb 09 2016, Paul Eggert wrote:

>> I think, (g)calloc and hybrid_calloc are still needed, though?
> I suppose you're right, so I installed your patch in master.

Thanks, I could have pushed it myself, I just posted it here to avoid
interfering with your plans concerning this stuff.

> this stuff is all pretty iffy. Why does Emacs redefine calloc but not
> aligned_alloc or posix_memalign, for example?

Here on FreeBSD 10, in the non-hybrid case both aligned_alloc and
posix_memalign are redefined; in the hybrid case there is only

/opt/src/emacs-calloc-non-hybrid;!2;: nm -g src/emacs | grep align
00000000005e4210 R QCalign_to
0000000000b83df8 D _aligned_blocks
0000000000b83df0 D _aligned_blocks_mutex
00000000005c92b0 T aligned_alloc
00000000005c8e70 T galigned_alloc
00000000005c90e0 T memalign
00000000005c90f0 T posix_memalign
/opt/src/emacs-calloc-non-hybrid;!3;: cd ../emacs-calloc-hybrid/
/opt/src/emacs-calloc-hybrid;!4;: nm -g src/emacs | grep align
00000000005e3380 R QCalign_to
                 U aligned_alloc@@FBSD_1.3
00000000005c71a0 T hybrid_aligned_alloc

> Is it because we know no library uses these newer allocators?

Just for the record, as you know this stuff way better than I do:

IIUC, we need hybrid_ versions for all allocation functions that are
actually used in code statically linked with emacs (at least those which
somewhere refer to memory allocated before dumping, but I don't think
there's much point in making a distinction here).

On the other hand, in the non-hybrid case, we have to override all of
them (if they exist in libc), so that references in shared libraries
linked with emacs to, say, posix_memalign don't resolve to the libc

> Anyway, I suppose it's better to play it safe and continue to redefine
> calloc, the way Emacs has done for decades, until we have a better way
> to do dumping and restoring and memory allocation for such.

In the hybrid case we just do #define calloc hybrid_calloc etc. in the
emacs sources, so that's not a problem.  On the other hand, in the
non-hybrid case, what has been done for decades (i.e. overriding the
libc implementation of calloc etc.) has turned out to be a problem after
all (bug#22085).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]