From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.comp.lib.glibc.alpha Subject: Re: Removal of unexec support from glibc malloc Date: Wed, 27 Jan 2016 18:02:12 +0200 Message-ID: <83r3h3yprv.fsf@gnu.org> References: <569CDB81.6040600@redhat.com> <569D3BE0.6050103@cs.ucla.edu> <569D4207.4060209@cs.ucla.edu> <569D6AE6.1060008@redhat.com> <83bn8icjqu.fsf@gnu.org> <83r3h86aqf.fsf@gnu.org> <56A7F07F.9000109@redhat.com> <83vb6fzo82.fsf@gnu.org> <56A88821.4020701@redhat.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453910542 22536 80.91.229.3 (27 Jan 2016 16:02:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jan 2016 16:02:22 +0000 (UTC) Cc: emacs-devel@gnu.org, libc-alpha@sourceware.org, rms@gnu.org, monnier@iro.umontreal.ca To: Florian Weimer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 27 17:02:17 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aOSXs-0004Tf-GV for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2016 17:02:12 +0100 Original-Received: from localhost ([::1]:51179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOSXr-00067t-Rq for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2016 11:02:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOSXb-00065S-FP for emacs-devel@gnu.org; Wed, 27 Jan 2016 11:01:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOSXW-0007ie-P6 for emacs-devel@gnu.org; Wed, 27 Jan 2016 11:01:55 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOSXW-0007iZ-MG; Wed, 27 Jan 2016 11:01:50 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2007 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aOSXO-00051R-It; Wed, 27 Jan 2016 11:01:43 -0500 In-reply-to: <56A88821.4020701@redhat.com> (message from Florian Weimer on Wed, 27 Jan 2016 10:04:33 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198911 gmane.comp.lib.glibc.alpha:59014 Archived-At: > Cc: rms@gnu.org, libc-alpha@sourceware.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > 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.