simplify GNU Emacs builds by replacing malloc

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

simplify GNU Emacs builds by replacing malloc

Paul Eggert
In Bug#27416 I propose replacing Emacs's hybrid malloc implementation on GNUish
platforms with a hybrid implementation that redefines malloc instead of
re-#defining it. That is, instead of defining a function hybrid_malloc that can
call either gmalloc or the system malloc (and using the macro "#define malloc
hybrid_malloc" in Emacs code), Emacs defines a function malloc that can call
either gmalloc or the system malloc (via the latter’s alternate name
‘__libc_malloc’), without using a macro.

Under this proposal, the Emacs build process no longer needs to compile library
files twice. For example, it can simply build lib/gettime.o from lib/gettime.c,
rather than having to build both lib/gettime.o and lib/e-gettime.o. This is
because there is only one malloc symbol used by Emacs code, not two.

The hybrid malloc approach would not change on non-GNUish platforms.

Although this change seems like an obvious win in that it should make Emacs a
bit easier to build and debug, I’m mentioning it on emacs-devel first in case
anyone sees a problem with it.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27416

Reply | Threaded
Open this post in threaded view
|

Re: simplify GNU Emacs builds by replacing malloc

John Wiegley
>>>>> "PE" == Paul Eggert <[hidden email]> writes:

PE> The hybrid malloc approach would not change on non-GNUish platforms.

PE> Although this change seems like an obvious win in that it should make
PE> Emacs a bit easier to build and debug, I’m mentioning it on emacs-devel
PE> first in case anyone sees a problem with it.

Was there any particular reason for the macro approach?

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|

Re: simplify GNU Emacs builds by replacing malloc

Paul Eggert
On 06/21/2017 11:29 PM, John Wiegley wrote:
> Was there any particular reason for the macro approach?


Which macro approach, the approach currently in Emacs, or the approach
proposed in Bug#27416? If the former, we have to be careful about
redefining the malloc function, as this has undefined behavior in C;
this is why Emacs #defines malloc instead. If the latter, it's a longer
story but that approach didn't work and the proposal has been withdrawn,
so I'm not sure it's worth taking the time to explain.


Reply | Threaded
Open this post in threaded view
|

Re: simplify GNU Emacs builds by replacing malloc

John Wiegley
>>>>> "PE" == Paul Eggert <[hidden email]> writes:

PE> On 06/21/2017 11:29 PM, John Wiegley wrote:
>> Was there any particular reason for the macro approach?

PE> Which macro approach, the approach currently in Emacs, or the approach
PE> proposed in Bug#27416? If the former, we have to be careful about
PE> redefining the malloc function, as this has undefined behavior in C; this
PE> is why Emacs #defines malloc instead. If the latter, it's a longer story
PE> but that approach didn't work and the proposal has been withdrawn, so I'm
PE> not sure it's worth taking the time to explain.

I meant the former, thanks for the clarification.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2