From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Camm Maguire Newsgroups: gmane.lisp.gcl.devel,gmane.linux.debian.ports.ia64,gmane.emacs.devel Subject: ia64 function descriptors and unexec Date: 29 Oct 2003 10:20:36 -0500 Sender: gcl-devel-bounces+gnu-gcl-devel=m.gmane.org@gnu.org Message-ID: <54vfq8t6ij.fsf_-_@intech19.enhanced.com> References: <20031025183937.GB21046@nevyn.them.org> <543cddb93x.fsf@intech19.enhanced.com> <20031028165700.GA1308@nevyn.them.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067441039 16670 80.91.224.253 (29 Oct 2003 15:23:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2003 15:23:59 +0000 (UTC) Cc: bdale@gag.com, 204789@bugs.debian.org, 217484@bugs.debian.org, debian-ia64@lists.debian.org, gcl-devel@gnu.org, emacs-devel@gnu.org Original-X-From: gcl-devel-bounces+gnu-gcl-devel=m.gmane.org@gnu.org Wed Oct 29 16:23:54 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AEsAs-0003LU-00 for ; Wed, 29 Oct 2003 16:23:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AEs8S-0003Dt-6R for gnu-gcl-devel@m.gmane.org; Wed, 29 Oct 2003 10:21:24 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AEs8G-0002w5-JV for gcl-devel@gnu.org; Wed, 29 Oct 2003 10:21:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AEs7j-0002NN-M5 for gcl-devel@gnu.org; Wed, 29 Oct 2003 10:21:10 -0500 Original-Received: from [66.134.96.17] (helo=intech19.enhanced.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AEs7i-0002M8-VG; Wed, 29 Oct 2003 10:20:39 -0500 Original-Received: from camm by intech19.enhanced.com with local (Exim 3.35 #1 (Debian)) id 1AEs7g-0003Rt-00; Wed, 29 Oct 2003 10:20:36 -0500 Original-To: Daniel Jacobowitz In-Reply-To: <20031028165700.GA1308@nevyn.them.org> Original-Lines: 163 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-BeenThere: gcl-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcl-devel-bounces+gnu-gcl-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.gcl.devel:2444 gmane.linux.debian.ports.ia64:777 gmane.emacs.devel:17550 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17550 Greetings! I've added Bdale and emacs-devel to the CC list, as I believe they have already found some work around for gnu emacs, a description of which would help me greatly. To sum up the previous discussion, the ia64 linux ABI apparently offers no opportunity for ld.so to ensure that function descriptors remain constant, even over successive executions of the same binary on the same machine. Any unexec'ed image which has saved "function pointers" in its .data section will therefore likely be corrupt on re-execution, as the saved function descriptors, even when simply referring to functions in the same program, will likely not correspond to the freshly allocated new ones. I believe that this issue stood in the way of an emacs port to ia64 linux for some time, and that Bdale contributed a fix, but I can't find it in the archives or in the current source. GCL's best bet now appears to be to implement this work around if possible, and if not, to try to find and dump the old ld.so function descriptor table into the saved image at unexec time. Help much appreciated! A few other comments below: Daniel Jacobowitz writes: > On Tue, Oct 28, 2003 at 11:49:38AM -0500, Camm Maguire wrote: > > Greetings, and thank you so much for your reply on this issue! > > > > Please let me preface the below with the statement that these are, of > > course, my opinions only, and that there may well be issues of which > > I'm unaware which may contraindicate my conclusions. > > > > Briefly, I think this is a bug in libc6 because: > > > > 1) It makes stable unexeced binary images, to my understanding, > > impossible. > > Unexecing has never, however, worked portably. I think emacs even > moved away from it, though I'm not sure of that. > To my knowledge, emacs still uses unexec. Xemacs uses something else. > > base, I cannot find it. I've had a helpful suggestion from a > > reader of debian-ia64 that I should modify the gcl's unexec to dump > > the portion of the descriptor table containing internal function > > addresses into the image itself as a runtime override of ld.so's > > work, but this appears both desperate and fragile. > > The alternatives are also desperate and fragile. That at least limits > the damage to gcl. > Fair enough. Didn't know how bad those suggestions would be vis a vis libc6. > > 2) ld.so's changing of the function descriptor table is (apparently) > > unnecessary, albeit possibly permitted by the ABI. To my > > knowledge, the Debian port to hppa faced similar issues, yet the > > implementation arrived at is free of this problem. In addition, > > the same helpful respondent referred to above suggested three ways > > in which this problem could be addressed at the ld.so level: > > The way that hppa does this is, I think, very different. Two of the Do you mean the ABI is different, i.e. does provide an opportunity to ensure constant function descriptors? To my knowledge, hpux on this hardware has the same issue, yet (Debian) linux is free from it. > suggestions below require substantial changes to the static linker and > some fudging with the ABI. Using sbrk would probably not solve the > issue at all. I understand that such changes may be inadvisable due to the scope of both the work required and the functionality affected, but, hypothetically speaking, would such an implementation once achieved 1) still conform to the ABI, 2) operate stably, and 3) be arguably preferable from a design standpoint? For the sake of the new readers, these suggestions were: ============================================================================= > If this analysis is correct, I suspect there are multiple ways to fix > the problem: > > - One possibility might be to have the link editor reserve the > necessary space so that make_fptr_table() can map this reserved > space, rather than allocating anonymous memory via mmap(). > Downside: requires changed to both the link-editor and the runtime > loader and I'm not sure how the runtime loader would locate the > reserved-space section. > > - Another possibility might be to change make_fptr_table() to use > sbrk() instead of mmap() when it allocates the descriptor table for > the main program. Downside: I'm not sure it's safe for the runtime > loader to change the process' break-value. > > - A third possibility might be to materialize function pointers for > the executable program at link time (rather than at load time). I > think the ELF symbol resolution rules would allow that, but I'm not > sure whether it would be easy to make these descriptors visible to > shared objects. > > Hmmh, none of these look terribly attractive to me. Richard, what do > you think? > ============================================================================= > > > 3) The ld.so ia64-specific behavior is clearly the root of the tree of > > these problems, and is the logical place to address them all once > > and for all. And, unless the ABI mandates that the descriptors > > *must* change across runs, implementing the descriptor table > > creation in a manner consistent with function addressing use on all > > the other Debian platforms is bound to improve the consistency, > > continuity, and robustness of the distro as a whole. To be more > > precise, the alternative to an ld.so fix is for every program from > > now on which ever uses unexec to put in and maintain lengthy ia64 > > specific #ifdef'ed modifications. > > > > Anyway, these are just my thoughts. > > There is a flaw in your logic. It's not "the ABI mandates that the > descriptors *must* change across runs" so much as "the ABI offers no > opportunity to *ensure* that descriptors do not change across runs". > > If anything this is a problem with the ia64 linux ABI; take it up with You know, if I can find the time, I just might, as this appears quite broken. Its obviously too late for ia64, but I've heard that similar things are in the plans for newer arches, and I think some feedback on this issue should be heard before this problem spreads. To whom should I write? > them. It can not be solved contained in glibc. > I take it this means cooperation would be needed from ld/gcc. Thanks for your very helpful reply! I'm going to look for a gcl work-around now (as the changes required otherwise are too far reaching to be good for Debian as a whole), and if I can find one, I'll drop this bug completely. Take care, > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > > > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah