all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Yavor Doganov <yavor@gnu.org>, rms <rms@gnu.org>,
	richardeng <richardeng@foxmail.com>,
	emacs-devel <emacs-devel@gnu.org>
Subject: Re: Emacs on GNUstep (was: Release update)
Date: Sat, 02 May 2009 15:28:18 +0900	[thread overview]
Message-ID: <wlk550nhml.wl%mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <jwvhc5ir5g5.fsf-monnier+emacs@gnu.org>

>>>>> On Fri, 05 Dec 2008 10:49:42 -0500, Stefan Monnier <monnier@iro.umontreal.ca> 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




  parent reply	other threads:[~2009-05-02  6:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-02  2:43 Release update Chong Yidong
2008-12-04 17:08 ` Yavor Doganov
2008-12-04 18:50   ` Ted Zlatanov
2008-12-04 19:29     ` Chong Yidong
2008-12-04 19:46       ` Ted Zlatanov
2008-12-04 22:55       ` Adrian Robert
2008-12-08 16:42         ` Ted Zlatanov
2008-12-05  2:12     ` Randal L. Schwartz
2008-12-05  2:44       ` Randal L. Schwartz
2008-12-04 19:43   ` Stefan Monnier
2008-12-04 19:45   ` Dan Nicolaescu
2008-12-05 12:08   ` Richard M Stallman
2008-12-05 12:44   ` richardeng
2008-12-05 15:49     ` Emacs on GNUstep (was: Release update) Stefan Monnier
2008-12-06  4:44       ` Stephen J. Turnbull
2008-12-06  6:59       ` richardeng
2008-12-06  7:54         ` Stephen J. Turnbull
2008-12-06 16:05         ` richardeng
2008-12-06 17:22           ` Emacs on GNUstep Chong Yidong
2009-05-02  6:28       ` YAMAMOTO Mitsuharu [this message]
2009-05-03 19:38         ` Stefan Monnier
2009-05-04  8:16           ` YAMAMOTO Mitsuharu
2009-05-04 13:45             ` Stefan Monnier
2009-05-06  2:36               ` YAMAMOTO Mitsuharu
2009-05-06 14:18                 ` Stefan Monnier
2009-05-03 22:45         ` Emacs on GNUstep (was: Release update) Yavor Doganov
2009-05-04  8:47           ` YAMAMOTO Mitsuharu
2008-12-04 19:51 ` Release update Dan Nicolaescu
2008-12-04 21:43   ` Chong Yidong
2008-12-04 22:27     ` Dan Nicolaescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wlk550nhml.wl%mituharu@math.s.chiba-u.ac.jp \
    --to=mituharu@math.s.chiba-u.ac.jp \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=richardeng@foxmail.com \
    --cc=rms@gnu.org \
    --cc=yavor@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.