This is the mail archive of the 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]

Re: Removal of unexec support from glibc malloc

> Cc:,,,
> From: Florian Weimer <>
> 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
> brittle.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]