emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs on GNUstep (was: Release update)


From: YAMAMOTO Mitsuharu
Subject: Re: Emacs on GNUstep (was: Release update)
Date: Sat, 02 May 2009 15:28:18 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Fri, 05 Dec 2008 10:49:42 -0500, Stefan Monnier <address@hidden> 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
                                address@hidden

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]