unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
Cc: emacs-devel@gnu.org
Subject: Re: 64-bit lossage
Date: Sun, 21 Jul 2002 07:35:21 -0400	[thread overview]
Message-ID: <tx1vg79b9fq.fsf@raeburn.org> (raw)
In-Reply-To: <rzqofdrh16a.fsf@albion.dl.ac.uk> (Dave Love's message of "01 Jul 2002 17:18:21 +0100")

Dave Love <d.love@dl.ac.uk> writes:
> It looks as though the current code is broken generally on 64-bit
> systems (by induction from alpha-osf and mips-sgi, so not

Which OS are you using on the Alpha?

On the 5.1 machine I've got at work, with a source tree I've already
started banging on for some of the lisp implementation issues I was
complaining about recently, I'm having some problems with mmap.  Not
using mmap for buffer storage seems to fix the problem for the moment,
but I'll investigate that further.

This debugging is more tedious than expected -- no dbx license
installed, and gdb-3.1 doesn't work.  Let's hear it for printf! :-)

I also noticed a number of compiler warnings about pointer mismatches
where the pointer targets were of the wrong type (e.g., int vs long);
I'll try to clean some of that up later.  But they kind of get lost
in the long list of complaints about mixing "char *" and "unsigned
char *".

> endian-related).  I don't know since when, but it predates the
> emacs-unicode branch, which it's hampering me working on.  The symptom
> is a crash (segv, if I remember correctly) in GC during dumping.

My problem showed up in some buffer manipulation code, so maybe it's
not the same problem.  But like I said, I've already started making
other changes in my tree....  Could you try the patch below?

If it works, try re-enabling the use of mmap and see if that part is
working on your system.

It's not ready to be checked in, but your results will let me know if
I'm on the right track.

Ken


Index: mem-limits.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/mem-limits.h,v
retrieving revision 1.29
diff -p -u -r1.29 mem-limits.h
--- mem-limits.h	11 Dec 2001 22:18:16 -0000	1.29
+++ mem-limits.h	21 Jul 2002 11:18:17 -0000
@@ -81,8 +81,10 @@ extern POINTER start_of_data ();
 
 #ifdef BSD_SYSTEM
 #ifndef DATA_SEG_BITS
+#ifndef DATA_START
 extern char etext;
 #define start_of_data() &etext
+#endif
 #endif
 #endif
 
Index: puresize.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/puresize.h,v
retrieving revision 1.65
diff -p -u -r1.65 puresize.h
--- puresize.h	16 Apr 2002 17:27:42 -0000	1.65
+++ puresize.h	21 Jul 2002 11:18:17 -0000
@@ -42,7 +42,7 @@ Boston, MA 02111-1307, USA.  */
 #endif
 
 #ifndef BASE_PURESIZE
-#define BASE_PURESIZE (830000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA)
+#define BASE_PURESIZE (930000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA)
 #endif
 
 /* Increase BASE_PURESIZE by a ratio depending on the machine's word size.  */
Index: m/alpha.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/m/alpha.h,v
retrieving revision 1.45
diff -p -u -r1.45 alpha.h
--- m/alpha.h	15 Apr 2002 13:16:00 -0000	1.45
+++ m/alpha.h	21 Jul 2002 11:18:17 -0000
@@ -29,8 +29,6 @@ NOTE-END
 
 */
 
-#define BITS_PER_LONG 64
-#define BITS_PER_EMACS_INT 64
 #ifndef _LP64
 #define _LP64			/* This doesn't appear to be necessary
 				   on OSF 4/5  -- fx.  */
@@ -56,14 +54,8 @@ NOTE-END
 
 /* Use type EMACS_INT rather than a union, to represent Lisp_Object */
 /* This is desirable for most machines.  */
-
 #define NO_UNION_TYPE
 
-/* Define the type to use.  */
-#define EMACS_INT long
-#define EMACS_UINT unsigned long
-#define SPECIAL_EMACS_INT
-
 /* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend
    the 24-bit bit field into an int.  In other words, if bit fields
    are always unsigned.
@@ -113,6 +105,7 @@ NOTE-END
 #ifdef __ELF__
 #undef UNEXEC
 #define UNEXEC unexelf.o
+#define DATA_START    0x140000000
 #endif
 
 #ifndef __ELF__
@@ -122,11 +115,6 @@ NOTE-END
 #define TEXT_START    0x120000000
 #define DATA_START    0x140000000
 
-/* This is necessary for mem-limits.h, so that start_of_data gives
-   the correct value */
-
-#define DATA_SEG_BITS 0x140000000
-
 /* The program to be used for unexec. */
 
 #define UNEXEC unexalpha.o
@@ -164,28 +152,6 @@ NOTE-END
 #define LINUX_SBRK_BUG
 #endif
 
-
-#define PNTR_COMPARISON_TYPE unsigned long
-
-/* On the 64 bit architecture, we can use 60 bits for addresses */
-
-#define VALBITS         60
-
-
-/* This definition of MARKBIT is necessary because of the comparison of
-   ARRAY_MARK_FLAG and MARKBIT in an #if in lisp.h, which cpp doesn't like. */
-
-#define MARKBIT         0x8000000000000000L
-
-
-/* Define XINT and XUINT so that they can take arguments of type int */
-
-#define XINT(a)  (((long) (a) << (BITS_PER_LONG - VALBITS)) >> (BITS_PER_LONG - VALBITS))
-#define XUINT(a) ((long) (a) & VALMASK)
-
-/* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
-
-#define XPNTR(a) XUINT (a)
 
 #ifndef NOT_C_CODE
 /* We need these because pointers are larger than the default ints.  */
Index: s/osf5-0.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/s/osf5-0.h,v
retrieving revision 1.6
diff -p -u -r1.6 osf5-0.h
--- s/osf5-0.h	10 Oct 2001 12:21:58 -0000	1.6
+++ s/osf5-0.h	21 Jul 2002 11:18:17 -0000
@@ -24,4 +24,4 @@
 /* We have missing/inconsistent prototypes on 5.0, at least.  */
 #define INHIBIT_X11R6_XIM
 
-#define USE_MMAP_FOR_BUFFERS	1
+/*#define USE_MMAP_FOR_BUFFERS	1*/

  parent reply	other threads:[~2002-07-21 11:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-01 16:18 64-bit lossage Dave Love
2002-07-02 19:45 ` Richard Stallman
2002-07-03 18:49   ` Andreas Schwab
2002-07-17 11:25     ` Dave Love
2002-07-17 19:47       ` Andreas Schwab
2002-07-22 16:08         ` Dave Love
2002-07-22 18:52           ` Ken Raeburn
2002-07-17 11:24   ` Dave Love
2002-07-17 12:43     ` Stefan Monnier
2002-07-18 14:55     ` Richard Stallman
2002-07-18 22:23       ` Ken Raeburn
2002-07-19 20:56         ` Richard Stallman
2002-07-20 21:58           ` Ken Raeburn
2002-07-23 22:09         ` Dave Love
2002-07-24 13:34           ` Ken Raeburn
2002-07-29 22:35             ` Dave Love
2002-07-21 11:35 ` Ken Raeburn [this message]
2002-07-21 14:05   ` Ken Raeburn
2002-07-23 22:14     ` Dave Love
2002-07-23 22:12   ` Dave Love
2002-07-26  7:02     ` Ken Raeburn
2002-07-29 22:43       ` Dave Love
2002-07-30 14:56         ` Ken Raeburn
2002-07-31  5:55           ` Richard Stallman
2002-08-01 17:19             ` Ken Raeburn
2002-08-01 21:19               ` Paul Eggert
2002-08-01 23:37                 ` Ken Raeburn
2002-08-01 23:50                   ` Paul Eggert
2002-08-03  7:48                     ` Ken Raeburn
2002-08-02 22:13                 ` Richard Stallman
2002-08-03  0:03                   ` Paul Eggert
2002-08-04 23:24                     ` Richard Stallman
2002-08-09  7:07                 ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=tx1vg79b9fq.fsf@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=emacs-devel@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).