Re: Removal of unexec support from glibc malloc

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

>>>>> Ali Bahrami <ali_gnu2@emvision.com> writes:

> Unexec is complicated, and it is a problem for alternative non-brk based
> mallocs, or ASLR. One of the strong design points of emacs is its use of a
> minimal and simple C core, with the system largely written in lisp. Losing
> unexec would leave an even simpler core.

> Before you fight to to save unexec, I'd encourage you to measure the impact,
> and see if it still matters. If it does, then it would be worthwhile to
> consider other means for getting those bytes into memory quickly that don't
> involve second guessing object layout, memory allocation, and process
> layout. Speaking as a linker guy, linking is only going to get more dynamic,
> and more complex, going forward. You might be glad, down the road, to be out
> of that game.

> That's not to say that John's concerns above aren't reasonable. This is big
> enough that you don't want to force it, but perhaps it's time to start
> considering alternatives.

I agree with what you're saying. Several voices have already voiced that we'd
like to move away from the complexity of "being in the malloc business"
(thanks, Paul). Now I'd like to know what it will take to get us there.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]