alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE

alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE

[Barry Fishman]

Building the CVS head on a adm64 running SuSE Linux 9.1, linking fails
with missing function mark_maybe_object().

This is due to a problem in alloc.c.  The static function
mark_maybe_object() is not defined when GC_MARK_STACK is zero but
is still used in mark_object() for 'case Lisp_Misc_Save_Value:'.

I don't understand the code well enough to suggest a patch.

-- 
Barry Fishman

x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE)

[Barry Fishman]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

I was unable to make any change to alloc.c that would fix the GC_MARK_STACK
problem without later crashes in the build while compiling the lisp
files.

However, I suspect the attached change to src/s/gnu-linux.h is
approprate.  This produces a working emacs (for me) on a amd64
gnu-linux system (SuSE 9.1), although it sidesteps the problem in
alloc.c.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Add __amd64__ to systems like __i386__ --]
[-- Type: text/x-patch, Size: 916 bytes --]

Index: gnu-linux.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/s/gnu-linux.h,v
retrieving revision 1.89
diff -c -r1.89 gnu-linux.h
*** gnu-linux.h	1 Sep 2003 15:45:58 -0000	1.89
--- gnu-linux.h	6 Jul 2004 23:49:36 -0000
***************
*** 355,361 ****
  
  #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
      || defined __alpha__ || defined __mips__ || defined __s390__ \
!     || defined __arm__ || defined __powerpc__
  #define GC_SETJMP_WORKS 1
  #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
  #ifdef __mc68000__
--- 355,361 ----
  
  #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
      || defined __alpha__ || defined __mips__ || defined __s390__ \
!     || defined __arm__ || defined __powerpc__ || defined __amd64__
  #define GC_SETJMP_WORKS 1
  #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
  #ifdef __mc68000__

[-- Attachment #3: Type: text/plain, Size: 19 bytes --]


-- 
Barry Fishman

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE)

[Kim F. Storm]

Barry Fishman <barry_fishman@att.net> writes:

> I was unable to make any change to alloc.c that would fix the GC_MARK_STACK
> problem without later crashes in the build while compiling the lisp
> files.

Does the following patch work (if you undo the patch you suggested below)?


*** alloc.c	23 Jun 2004 10:30:52 +0200	1.346
--- alloc.c	12 Jul 2004 11:29:19 +0200	
***************
*** 5033,5038 ****
--- 5033,5039 ----
  	  break;
  
  	case Lisp_Misc_Save_Value:
+ #if GC_MARK_STACK
  	  {
  	    register struct Lisp_Save_Value *ptr = XSAVE_VALUE (obj);
  	    /* If DOGC is set, POINTER is the address of a memory
***************
*** 5045,5050 ****
--- 5046,5052 ----
  		  mark_maybe_object (*p);
  	      }
  	  }
+ #endif
  	  break;
  
  	case Lisp_Misc_Overlay:

> 
> However, I suspect the attached change to src/s/gnu-linux.h is
> approprate.  This produces a working emacs (for me) on a amd64
> gnu-linux system (SuSE 9.1), although it sidesteps the problem in
> alloc.c.

This is a good change -- have you been using that for some time
now without problems?  If so, I will commit your patch.

> 
> Index: gnu-linux.h
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/s/gnu-linux.h,v
> retrieving revision 1.89
> diff -c -r1.89 gnu-linux.h
> *** gnu-linux.h	1 Sep 2003 15:45:58 -0000	1.89
> --- gnu-linux.h	6 Jul 2004 23:49:36 -0000
> ***************
> *** 355,361 ****
>   
>   #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
>       || defined __alpha__ || defined __mips__ || defined __s390__ \
> !     || defined __arm__ || defined __powerpc__
>   #define GC_SETJMP_WORKS 1
>   #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
>   #ifdef __mc68000__
> --- 355,361 ----
>   
>   #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
>       || defined __alpha__ || defined __mips__ || defined __s390__ \
> !     || defined __arm__ || defined __powerpc__ || defined __amd64__
>   #define GC_SETJMP_WORKS 1
>   #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
>   #ifdef __mc68000__
> 
> -- 
> Barry Fishman
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE)

[Barry Fishman]

storm@cua.dk (Kim F. Storm) writes:

> Barry Fishman <barry_fishman@att.net> writes:
>
>> I was unable to make any change to alloc.c that would fix the GC_MARK_STACK
>> problem without later crashes in the build while compiling the lisp
>> files.
>
> Does the following patch work (if you undo the patch you suggested below)?
>
[patch skipped]

That was my first attempt at fixing the problem. The emacs (bootstrap)
build then failed later on during a lisp compile.  I could not
diagnose what was causing it, but at the time assumed it was a
garbage collector problem.

Trying it again I get the following during a bootstrap build:

In completion-c-mode-hook:
completion.el:2354:15:Warning: reference to free variable `c-mode-map'

In completion-setup-fortran-mode:
completion.el:2364:15:Warning: reference to free variable `fortran-mode-map'
Wrote /home/barry/src/gen/emacs/lisp/completion.elc
Compiling /home/barry/src/gen/emacs/lisp/./composite.el
Wrote /home/barry/src/gen/emacs/lisp/composite.elc
Compiling /home/barry/src/gen/emacs/lisp/./cus-dep.el
Wrote /home/barry/src/gen/emacs/lisp/cus-dep.elc
Compiling /home/barry/src/gen/emacs/lisp/./cus-edit.el
Wrote /home/barry/src/gen/emacs/lisp/cus-edit.elc
Compiling /home/barry/src/gen/emacs/lisp/./cus-face.el
Wrote /home/barry/src/gen/emacs/lisp/cus-face.elc
Compiling /home/barry/src/gen/emacs/lisp/./cus-start.el
Wrote /home/barry/src/gen/emacs/lisp/cus-start.elc
Compiling /home/barry/src/gen/emacs/lisp/./cus-theme.el
Fatal error (11)make[1]: *** [compile] Error 1
make[1]: Leaving directory `/home/barry/src/gen/emacs/lisp'
make: *** [bootstrap] Error 2
 
>> However, I suspect the attached change to src/s/gnu-linux.h is
>> approprate.  This produces a working emacs (for me) on a amd64
>> gnu-linux system (SuSE 9.1), although it sidesteps the problem in
>> alloc.c.
>
> This is a good change -- have you been using that for some time
> now without problems?  If so, I will commit your patch.

I have been using it since July 6 without problems.  Am I the only
one using emacs on a amd64 gnu-linux kernel?  

I used the __amd64__ C define to identify the x86_64 processor.  Under
SuSE 9.1 (gcc 3.3.3) __x86_64__ is also automatically defined.  I
don't know if there is any advantage in picking one over the other.
The rest of the emacs sources does not seem to make this check
although the src/m/amdx86-64.h file wrongly declares that __x86_64 is
defined automatically.

-- 
Barry Fishman

Re: x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE)

[Kim F. Storm]

Barry Fishman <barry_fishman@att.net> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Barry Fishman <barry_fishman@att.net> writes:
> >
> >> I was unable to make any change to alloc.c that would fix the GC_MARK_STACK
> >> problem without later crashes in the build while compiling the lisp
> >> files.
> >
> > Does the following patch work (if you undo the patch you suggested below)?
> >
> [patch skipped]
> 
> That was my first attempt at fixing the problem. The emacs (bootstrap)
> build then failed later on during a lisp compile.  I could not
> diagnose what was causing it, but at the time assumed it was a
> garbage collector problem.
> 
> Trying it again I get the following during a bootstrap build:

I have been running with the patch and GC_USE_GCPROS_AS_BEFORE for a week
now without any problems, and studying the code doesn't indicate to me
what's wrong.

You could try to run the ./temacs command under gdb to see where the
program traps.  You can see the required parameters in the make output.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE)

[Kim F. Storm]

I have installed your patch in CVS.  Thank you.


Barry Fishman <barry_fishman@att.net> writes:

> I was unable to make any change to alloc.c that would fix the GC_MARK_STACK
> problem without later crashes in the build while compiling the lisp
> files.
> 
> However, I suspect the attached change to src/s/gnu-linux.h is
> approprate.  This produces a working emacs (for me) on a amd64
> gnu-linux system (SuSE 9.1), although it sidesteps the problem in
> alloc.c.
> 
> Index: gnu-linux.h
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/s/gnu-linux.h,v
> retrieving revision 1.89
> diff -c -r1.89 gnu-linux.h
> *** gnu-linux.h	1 Sep 2003 15:45:58 -0000	1.89
> --- gnu-linux.h	6 Jul 2004 23:49:36 -0000
> ***************
> *** 355,361 ****
>   
>   #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
>       || defined __alpha__ || defined __mips__ || defined __s390__ \
> !     || defined __arm__ || defined __powerpc__
>   #define GC_SETJMP_WORKS 1
>   #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
>   #ifdef __mc68000__
> --- 355,361 ----
>   
>   #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
>       || defined __alpha__ || defined __mips__ || defined __s390__ \
> !     || defined __arm__ || defined __powerpc__ || defined __amd64__
>   #define GC_SETJMP_WORKS 1
>   #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
>   #ifdef __mc68000__
> 
> -- 
> Barry Fishman
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk