This is the mail archive of the
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: rms at gnu dot org, libc-alpha at sourceware dot org, monnier at iro dot umontreal dot ca, emacs-devel at gnu dot org
- Date: Wed, 27 Jan 2016 18:02:12 +0200
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com> <569D4207 dot 4060209 at cs dot ucla dot edu> <569D6AE6 dot 1060008 at redhat dot com> <83bn8icjqu dot fsf at gnu dot org> <jwv60yk7snj dot fsf-monnier+gmane dot emacs dot devel at gnu dot org> <83r3h86aqf dot fsf at gnu dot org> <E1aN72k-00024K-Ep at fencepost dot gnu dot org> <56A7F07F dot 9000109 at redhat dot com> <83vb6fzo82 dot fsf at gnu dot org> <56A88821 dot 4020701 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
> From: Florian Weimer <email@example.com>
> Date: Wed, 27 Jan 2016 10:04:33 +0100
> > AFAIK, Emacs has no reason to call any libraries in temacs except libc
> > (and its logical extensions, like libm).
> ELF constructors still run.
By "ELF constructors", do you mean the .ctors and .init sections? If
so, those that belong to the libc startup code are what I called
"logical extensions of libc" above. And if you mean such sections in
3rd party libraries, we haven't met such libraries yet.
> Whether their effects are visible across dumps depends on which
> symbols are referenced from the main program. All this is rather
It works well in practice, though, have been working for 3 decades.
And that's not the most "brittle" stuff I bumped into while working on
Emacs, btw. If you are old enough, you might remember the days when
all the major supported platforms used gmalloc+ralloc in Emacs. In
those days there was a rule that you couldn't call libc functions that
might call 'malloc' internally, if you passed pointers to buffer text
to those functions -- because ralloc would sometimes relocate buffer
text as side effect of 'malloc'/'realloc' calls, and by doing that
invalidate those pointers. The first serious bug I needed to debug
when I started hacking Emacs, 20 years ago, was caused by a call to
'write' in write-region, which triggered such relocation, because the
particular libc involved had the audacity to call 'malloc' inside
'write' for whatever reasons, something Emacs code never expected,
since why would 'write' call 'malloc'? Now, _that_ is something I'd
call "brittle". And yet we lived with this for many years; when I
astonishingly described my findings to RMS back then, his answer was
basically "tough: that's what ralloc does, and it cannot be helped".
The fear of static constructors (which AFAIK never materialized) pales
in comparison, wouldn't you agree?
I'm not saying we shouldn't work towards removing these issues, but
it's not like we are faint at heart in these matters.