From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs on GNUstep (was: Release update) Date: Sat, 02 May 2009 15:28:18 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <87ej0rs3ey.fsf@cyd.mit.edu> <87tz9j6f76.GNU's_Not_Unix!%yavor@gnu.org> <200812052044154371169@foxmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1241245740 29398 80.91.229.12 (2 May 2009 06:29:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2009 06:29:00 +0000 (UTC) Cc: Yavor Doganov , rms , richardeng , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 08:28:44 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M08iI-0003KX-VI for ged-emacs-devel@m.gmane.org; Sat, 02 May 2009 08:28:44 +0200 Original-Received: from localhost ([127.0.0.1]:52220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M08iI-0003VD-9b for ged-emacs-devel@m.gmane.org; Sat, 02 May 2009 02:28:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M08iD-0003V8-3d for emacs-devel@gnu.org; Sat, 02 May 2009 02:28:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M08i8-0003Ub-A1 for emacs-devel@gnu.org; Sat, 02 May 2009 02:28:36 -0400 Original-Received: from [199.232.76.173] (port=33571 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M08i8-0003UY-3a for emacs-devel@gnu.org; Sat, 02 May 2009 02:28:32 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:59603) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M08i3-0006Tn-Ps; Sat, 02 May 2009 02:28:28 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2] helo=mathmail.math.s.chiba-u.ac.jp) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M08i2-0000hQ-LZ; Sat, 02 May 2009 02:28:27 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id A9EC32C43; Sat, 2 May 2009 15:28:18 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by mx20.gnu.org: NetBSD 3.0 (DF) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110602 Archived-At: >>>>> On Fri, 05 Dec 2008 10:49:42 -0500, Stefan Monnier said: >> Because my PC is slow, I've used WindowMaker(GNUStep) about 4 >> years. What kind of skills is needed to solve bugs under >> GNUStep(module name in bug description is NS?) It seem that only >> bugs related to Emacs.app belongs to NS, right? > IIUC the main problem with it right now is that it cannot be dumped. > I.e. we cannot perform the compilation step where we load `temacs', > then all the core Emacs files, and then dump the result into a new > executable `emacs'. This means that Emacs/GNUstep has to load all > the fils like subr.el, simple.el, text-mode.el, ... over and over > again at each startup, and it has several other nasty consequences. > Fixing this requires someone who can delve into the details of how > GNUstep binaries are layed out and how the ObjC runtime is linked > and initialized and how all this interacts. I just tried copying ObjC-related information in the .data section not from the dumping process but from the original temacs file so as to avoid some confusion during the startup time of the dumped executable. It seems to work for me at least on GNU/Linux (Ubuntu 9.04). YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp Index: src/unexelf.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/unexelf.c,v retrieving revision 1.71 diff -c -p -r1.71 unexelf.c *** src/unexelf.c 7 Feb 2009 13:07:39 -0000 1.71 --- src/unexelf.c 2 May 2009 06:23:18 -0000 *************** unexec (new_name, old_name, data_start, *** 1206,1216 **** symendp = (ElfW(Sym) *) ((byte *)symp + NEW_SECTION_H (n).sh_size); for (; symp < symendp; symp ++) ! if (strcmp ((char *) (symnames + symp->st_name), "_end") == 0 ! || strcmp ((char *) (symnames + symp->st_name), "end") == 0 ! || strcmp ((char *) (symnames + symp->st_name), "_edata") == 0 ! || strcmp ((char *) (symnames + symp->st_name), "edata") == 0) ! memcpy (&symp->st_value, &new_bss_addr, sizeof (new_bss_addr)); } /* This loop seeks out relocation sections for the data section, so --- 1206,1242 ---- symendp = (ElfW(Sym) *) ((byte *)symp + NEW_SECTION_H (n).sh_size); for (; symp < symendp; symp ++) ! { ! if (strcmp ((char *) (symnames + symp->st_name), "_end") == 0 ! || strcmp ((char *) (symnames + symp->st_name), "end") == 0 ! || strcmp ((char *) (symnames + symp->st_name), "_edata") == 0 ! || strcmp ((char *) (symnames + symp->st_name), "edata") == 0) ! memcpy (&symp->st_value, &new_bss_addr, sizeof (new_bss_addr)); ! ! /* ObjC runtime modifies the values of some data structures ! such as classes and selectors in the .data section after ! loading. As the dump process copies the .data section ! from the current process, that causes problems when the ! modified classes are reinitialized in the dumped ! executable. We copy such data from the old file, not ! from the current process. */ ! if (strncmp ((char *) (symnames + symp->st_name), ! "_OBJC_", sizeof ("_OBJC_") - 1) == 0) ! { ! caddr_t old, new; ! ! /* XXX: Check the section name of symp->st_shndx? */ ! new = ((symp->st_value - NEW_SECTION_H (symp->st_shndx).sh_addr) ! + NEW_SECTION_H (symp->st_shndx).sh_offset + new_base); ! /* "Unpatch" index. */ ! nn = symp->st_shndx; ! if (nn > old_bss_index) ! nn--; ! old = ((symp->st_value - NEW_SECTION_H (symp->st_shndx).sh_addr) ! + OLD_SECTION_H (nn).sh_offset + old_base); ! memcpy (new, old, symp->st_size); ! } ! } } /* This loop seeks out relocation sections for the data section, so