On Monday, 27 January 2003, Stephen J. Turnbull wrote: Maybe it has to do with 64-bit little endian. I never saw an XEmacs package for Linux/Alpha. Linux/IA64 is a similar beast. I have access to a linux/ia64 machine. I will give it a shot. -kitty.

On Sunday, 26 January 2003, Martin Buchholz wrote: Well, I still see some cast from pointer to integer of different size. Maybe they were added in new code. Upon further investigation, the crash happens in eval.c and I get three warnings in eval.c about truncation. FWIW, I am able to build and run on Linux/IA-64 with some tweaking. I however used GNU Emacs's src/m/ia64.h (edited ofcourse). Didn't know if that helped. My guess is that if the cast warnings are fixed in eval.c, we should be able to build on IA-64 without resorting to using --with-system-malloc. -kitty. Here is the installation info: uname -a: Linux toutatis 2.4.18-0.2a.1smp #1 SMP Fri May 31 14:03:13 EDT 2002 ia64 ia64 ia64 GNU/Linux ./configure '--cflags=-g' '--with-system-malloc' XEmacs 21.5-b10 "burdock" (+CVS-20030126) configured for `ia64-unknown-linux'. Compilation / Installation: Source code location: /u/kitty/tools/xemacs-21.5 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/ia64.h' Compiler: gcc -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wundef -Wstrict-prototypes -Wpacked -Wshadow -Wmissing-declarations -g Relocating allocator for buffers: no GNU version of malloc: no - User chose not to use GNU allocators. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Using the new portable dumper. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: ---------------------------------------------------------

On Monday, 27 January 2003, Stephen J. Turnbull wrote: Sorry for the late reply. See the attached files to this mail. One is the make output with ./configure --cflags="-g" and the other with ./configure --cflags="-g" --with-system-malloc I removed the src/m/ia64.h file as it didn't make any difference. I have also attached the config.log from the second build which should be identical to the first except for the malloc setting. Also I haven't built it using optimization. BTW, I am building with gcc-3.2.1 and glibc-2.3.1. I have also attached a backtrace when the crash happens. Also attached is the src/m/ia64.h so that knowledgeable people can add the right tweaks to XEmacs so that it doesn't give out a message that there is no machine description file. I didn't try with KKCC. Ping me if there is interest. The only possible screwup that can happen is that function pointers are very different on IA-64 than other platforms and are known to cause bad things as is shown below. So unless KKCC is playing tricks with that it should be good to go (I guess...). /---- | From: Keith Owens <kaos at sgi dot com> | To: Piet/Pete Delaney <piet at sgi dot com> | Cc: linux-ia64 at linuxia64 dot org, srn at engr dot sgi dot com, davidm at | Date: Thu, 03 Jan 2002 19:35:30 +1100 | Subject: Re: is casting of function descriptor assignments for ia64 ONLY a | good idea? | | On Wed, 2 Jan 2002 21:46:35 -0800, | Piet/Pete Delaney <piet(a)sgi.com&gt; wrote: | >SUMMARY: | > | > Keith Owens just pointed out that ia64 function descriptor | > assignments MUST be cast: | > | > pointer = ((unsigned long *)(&my_printf))[0]) | > | > howerver it appears that other platforms MUST NOT be cast. | > | >I was wondering if that a good idea. It seems it might require hacking | >a lot of existing code. | | The problem only arises if you want to print or store the location of | the function code. That is very rare, most of the time you just pass | function pointers around and let the compiler handle their format. | Think of a function pointer as an opaque cookie. | | >Why is this necessary for just ia64? | | Not just ia64, powerpc 64 as well. You are assuming that all pointers | are the same format when that is not guaranteed by the C standard. On | most architectures they are the same, you can convert a function | pointer to a void pointer and back again but it is not defined | behaviour. | | On IA64 and PPC64 the function pointer does not reference the function | itself, instead it points to a function descriptor. The function | descriptor contains a pointer to the function code plus additional data | such as a pointer to the global data to be used when the function is | called. This is mandated by the architecture software ABI. | | I had to solve this problem for my dynamic syscall patch[1] because the | syscall table points directly to the function code in the kernel, not | to the function descriptor, even on ia64. I define DYNAMIC_SYSCALL_T | and DYNAMIC_SYSCALL_FUNCADDR() which are asm specific. On most | systems, funcaddr is a noop. For i386 | | #define DYNAMIC_SYSCALL_T long | #define DYNAMIC_SYSCALL_FUNCADDR(f) (DYNAMIC_SYSCALL_T)(f) | | but on ia64 it does real work | | #define DYNAMIC_SYSCALL_T long long | #define DYNAMIC_SYSCALL_FUNCADDR(f) ({DYNAMIC_SYSCALL_T *fp = | #(DYNAMIC_SYSCALL_T *)(f); fp[0];}) | | BTW, the lack of a true descriptor for syscall entries is one reason | why trying to put syscalls in modules is a non-starter. The ia64 | syscall handler assumes that all syscall code is in the kernel using | the constant kernel global data pointer, so there is no need to change | the environment on a syscall. But syscalls in modules require a | different environment and there is nowhere to store the extra data in | the syscall table. \---- Hope this helps. -kitty. PS: Something is seriously broken with the -nw configuration in 21.5. Every command e.g M-x des-inst starts eating the window height and width, so that after a few commands (unsuccessful I might add), XEmacs shrinks :-) ---------- ------- ---- | | | | | | | | | | | ---> | | ---> ---- ----> Voila no XEmacs any more | ------- | --------- And I don't think it is IA-64 specific. kitty> bt #0 error_check_lcrecord_list (obj=0, file=0x40000000006c7c58 "alloc.c", #line=2585) at lrecord.h:1252 #1 0x400000000006a390 in alloc_managed_lcrecord (lcrecord_list=0) at #alloc.c:2585 #2 0x4000000000409330 in make_opaque_ptr (val=0x600000000003a7c0) at #opaque.c:157 #3 0x400000000016e5a0 in record_unwind_protect_restoring_int #(addr=0x600000000003a7c0, val=0) at eval.c:5840 #4 0x400000000016e6f0 in internal_bind_int (addr=0x600000000003a7c0, #newval=1) at eval.c:5860 #5 0x40000000000726f0 in begin_gc_forbidden () at alloc.c:4246 #6 0x400000000011b6f0 in emacs_vsprintf_string (format=0x40000000006c7b88 #"%s\nKilling some buffers may delay running out of memory.\nHowever, #certainly by the time you receive the 95%% warning,\nyou should clean up, #kill this Emacs, and start a new one.", vargs=0x80000fffffffb348) at #doprnt.c:822 #7 0x4000000000171480 in warn_when_safe (class_=0, level=0, #fmt=0x40000000006c7b88 "%s\nKilling some buffers may delay running out of #memory.\nHowever, certainly by the time you receive the 95%% warning,\nyou #should clean up, kill this Emacs, and start a new one.") at eval.c:6279 #8 0x400000000005c920 in malloc_warning (str=0x40000000006f7a60 "Warning: #past 75% of memory limit") at alloc.c:255 #9 0x40000000006718f0 in check_memory_limits () at vm-limit.c:84 #10 0x2000000000bc57f0 in sYSMALLOc (nb=16400, av=0x2000000000d289f8) at #malloc.c:2686 #11 0x2000000000bbfad0 in __libc_malloc (bytes=16384) at malloc.c:3292 #12 0x400000000005cf30 in xrealloc (block=0x0, size=16384) at alloc.c:336 #13 0x400000000011c5a0 in Dynarr_realloc (dy=0x6000000000170830, #new_size=16384) at dynarr.c:141 #14 0x400000000011c920 in Dynarr_resize (d=0x6000000000170830, size=1410) #at dynarr.c:171 #15 0x40000000000776a0 in init_alloc_once_early () at alloc.c:5069 #16 0x400000000013da50 in xemacs_21_5_b10_ia64_unknown_linux (argc=6, #argv=0x80000fffffffb6b8, envp=0x80000fffffffb6f0, restart=0) at #emacs.c:1158 #17 0x4000000000143bc0 in main (argc=6, argv=0x80000fffffffb6b8, #envp=0x80000fffffffb6f0) at emacs.c:2730 kitty> /* machine description file for the IA-64 architecture. Copyright (C) 2000, 2002 Free Software Foundation, Inc. Contributed by David Mosberger <davidm(a)hpl.hp.com&gt; This file is part of GNU Emacs. GNU Emacs is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Emacs; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #define BITS_PER_LONG 64 #define BITS_PER_EMACS_INT 64 /* Define WORDS_BIG_ENDIAN iff lowest-numbered byte in a word is the most significant byte. */ #undef WORDS_BIG_ENDIAN /* Define NO_ARG_ARRAY if you cannot take the address of the first of a group of arguments and treat it as an array of the arguments. */ #define NO_ARG_ARRAY /* Define WORD_MACHINE if addresses and such have to be corrected before they can be used as byte counts. */ /* #define WORD_MACHINE */ /* Now define a symbol for the cpu type, if your compiler does not define it automatically: Ones defined so far include vax, m68000, ns16000, pyramid, orion, tahoe, APOLLO and many others */ /* __ia64__ defined automatically */ /* 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. If you use NO_UNION_TYPE, this flag does not matter. */ #define EXPLICIT_SIGN_EXTEND /* Data type of load average, as read out of kmem. */ #define LOAD_AVE_TYPE long /* Convert that into an integer that is 100 for a load average of 1.0 */ #define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE) /* Define CANNOT_DUMP on machines where unexec does not work. Then the function dump-emacs will not be defined and temacs will do (load "loadup") automatically unless told otherwise. */ #if 0 #define CANNOT_DUMP #endif /* Define VIRT_ADDR_VARIES if the virtual addresses of pure and impure space as loaded can vary, and even their relative order cannot be relied on. Otherwise Emacs assumes that text space precedes data space, numerically. */ /* #define VIRT_ADDR_VARIES */ /* Define the following if GNU malloc and the relocating allocator do not work together with X. */ /* #define SYSTEM_MALLOC */ /* Define NO_REMAP if memory segmentation makes it not work well to change the boundary between the text section and data section when Emacs is dumped. If you define this, the preloaded Lisp code will not be sharable; but that's better than failing completely. */ /* #define NO_REMAP */ /* Some really obscure 4.2-based systems (like Sequent DYNIX) do not support asynchronous I/O (using SIGIO) on sockets, even though it works fine on tty's. If you have one of these systems, define the following, and then use it in config.h (or elsewhere) to decide when (not) to use SIGIO. You'd think this would go in an operating-system description file, but since it only occurs on some, but not all, BSD systems, the reasonable place to select for it is in the machine description file. */ /* #define NO_SOCK_SIGIO */ #ifdef __ELF__ #undef UNEXEC #define UNEXEC unexelf.o #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) #ifndef NOT_C_CODE #ifdef REL_ALLOC #ifndef _MALLOC_INTERNAL /* "char *" because ralloc.c defines it that way. gmalloc.c thinks it is allowed to prototype these as "void *" so we don't prototype in that case. You're right: it stinks! */ extern char *r_alloc (), *r_re_alloc (); extern void r_alloc_free (); #endif /* not _MALLOC_INTERNAL */ #endif /* REL_ALLOC */ #endif /* not NOT_C_CODE */ #define DATA_SEG_BITS 0x6000000000000000 #define HAVE_TEXT_START

Krishnakumar> PS: Something is seriously broken with the -nw Krishnakumar> configuration in 21.5. Every command e.g M-x Krishnakumar> des-inst starts eating the window height and width, Stephen> That's right. This is known, Mike is working on it. Woops, no, it wasn't. I horsed around with -nw quite a bit, and didn't see any problems, but I now see this one. (Can't imagine how I missed it.) I'll get to it, but it'll be later in the week or on the weekend. Thanks for the heads-up! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

mb> I fixed all the 64-bit bugs in XEmacs on DecOSF/Alpha, and mb> that platform worked fine at least until March 2001, when I mb> stopped regular testing. Yup. I believe I've seen a couple of success reports on that platform since Sept 2001 (when my DecOSF/Alpha box got reverted to a Solaris box), but it's definitely Martin's testing and the not so tender ministrations of the KKCC crowd that makes me think 21.4 might be a little cleaner. Mike, are your guys paying proper attention to 64-bit issues while you're doing surgery on the allocator? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.