[racket-dev] support for arm64 / aarch64
A user submitted the attached patch for partial support for arm64 on Debian/Ubuntu. It only enables cgc, 3m still hangs during compilation. If the patch makes sense to you, perhaps you'd like to apply it upstream. d From 7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1 Mon Sep 17 00:00:00 2001 From: Yvan Roux yvan.r...@linaro.org Date: Wed, 23 Jan 2013 23:15:57 +0400 Subject: [PATCH] Add AArch64 (64-bit ARM) target support * include/private/gcconfig.h (AARCH64): New macro (defined only if __aarch64__). * include/private/gcconfig.h (mach_type_known): Update comment adding ARM AArch64 target. * include/private/gcconfig.h (NOSYS, mach_type_known, CPP_WORDSZ, MACH_TYPE, ALIGNMENT, HBLKSIZE, OS_TYPE, LINUX_STACKBOTTOM, DYNAMIC_LOADING, DATASTART, DATAEND, STACKBOTTOM): Define for AArch64. --- include/private/gcconfig.h | 37 + 1 file changed, 37 insertions(+) --- a/src/racket/gc/include/private/gcconfig.h +++ b/src/racket/gc/include/private/gcconfig.h @@ -76,6 +76,13 @@ # endif /* Determine the machine type: */ +# if defined(__aarch64__) +#define AARCH64 +#if !defined(LINUX) +# define NOSYS +# define mach_type_known +#endif +# endif # if defined(__arm__) || defined(__thumb__) #define ARM32 #if !defined(LINUX) !defined(NETBSD) !defined(OPENBSD) @@ -249,6 +256,10 @@ #define IA64 #define mach_type_known # endif +# if defined(LINUX) defined(__aarch64__) +#define AARCH64 +#define mach_type_known +# endif # if defined(LINUX) defined(__arm__) #define ARM32 #define mach_type_known @@ -529,6 +540,7 @@ /* running Amdahl UTS4 */ /* S390 == 390-like machine */ /* running LINUX */ + /* AARCH64== ARM AArch64 */ /* ARM32 == Intel StrongARM */ /* IA64 == Intel IPF */ /* (e.g. Itanium) */ @@ -1818,6 +1830,31 @@ # endif # endif +# ifdef AARCH64 +# define CPP_WORDSZ 64 +# define MACH_TYPE AARCH64 +# define ALIGNMENT 8 +# ifndef HBLKSIZE +# define HBLKSIZE 4096 +# endif +# ifdef LINUX +# define OS_TYPE LINUX +# define LINUX_STACKBOTTOM +# define DYNAMIC_LOADING + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern char _end[]; +# define DATAEND ((ptr_t)(_end)) +# endif +# ifdef NOSYS + /* __data_start is usually defined in the target linker script. */ + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern void *__stack_base__; +# define STACKBOTTOM ((ptr_t)__stack_base__) +# endif +# endif + # ifdef ARM32 # define CPP_WORDSZ 32 # define MACH_TYPE ARM32 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Juan Francisco Cantero Hurtado wrote: Works fine on my machine. I've re-built the whole thing several times over the past few days and it does not fail every time. It has failed once out of the last three builds I did. Try with ulimit -d 100. My limit was already set at 1048576 :-) The racket process never reaches that size anyway. Here are two graphs showing the size of the process over time, for two different successful builds: http://www.ccs.neu.edu/home/meunier/chart1.pdf http://www.ccs.neu.edu/home/meunier/chart2.pdf There's one data point every second. The top and right edges of the graphs are the 1048576 KB limit. The maximum size reached (in the second build) was 900116 KB. Interestingly, even tough these two builds succeeded and finished normally, I noticed that they both gave this error message: raco setup: rendering: pkgs/images-doc/images/scribblings/images.scrbl unmap failed: 814000, 278528, 22 raco setup: rendering: pkgs/racket-doc/scribblings/inside/inside.scrbl In both builds the racket process was about 630 MB in size at the time this error message showed up. The place where this error message showed up is the exact same place in the build where racket failed in my original email... Now here is a graph for a build that failed: http://www.ccs.neu.edu/home/meunier/chart3.pdf It failed again while processing images.scrbl, but during the running part of the build this time, not the rendering part: raco setup: running: pkgs/images-doc/images/scribblings/images.scrbl Seg fault (internal error during gc) at 0xd98004 *** Signal SIGABRT in . (Makefile:62 'plain-in-place') *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place') The running: pkgs/.../images.scrbl is always the point in the build where the racket process reaches its maximum size (883864 KB in this case), but the process was already back down to about 584 MB when the internal error during gc message showed up. Here is the backtrace from gdb on the core file: (gdb) bt #0 0x04a78b01 in kill () at stdin:2 #1 0x04ae37f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x04ae3740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #3 0x16e9fc3c in fault_handler () from /home/meunier/lang/racket.new/racket/bin/racket #4 signal handler called #5 memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:66 #6 0x16ea64b9 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket #7 0x16e7de1f in scheme_register_traversers () from /home/meunier/lang/racket.new/racket/bin/racket #8 0x16ea6b54 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #9 0x16ea6c5d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #10 0x16ea37a6 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket #11 0x16ea5df4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket #12 0x16ea83ca in GC_malloc_atomic () from /home/meunier/lang/racket.new/racket/bin/racket #13 0x16ce7649 in scheme_generate_alloc_retry () from /home/meunier/lang/racket.new/racket/bin/racket #14 0x00236c9b in ?? () #15 0x in ?? () Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] support for arm64 / aarch64
It looks like this patch was submitted for v6.1. Version 6.1.1 (the current release), uses SGC instead of Boehm's GC during the build process by default. So, it at least avoids this immediate problem. I can't think of any other problem that would turn up in v6.1.1, but I'm not sure it will work. We'd definitely welcome feedback on whether Racket 6.1.1 builds on AArch64, or where it gets stuck if not. Thanks! At Mon, 29 Dec 2014 11:09:16 +0100, David Bremner wrote: A user submitted the attached patch for partial support for arm64 on Debian/Ubuntu. It only enables cgc, 3m still hangs during compilation. If the patch makes sense to you, perhaps you'd like to apply it upstream. d From 7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1 Mon Sep 17 00:00:00 2001 From: Yvan Roux yvan.r...@linaro.org Date: Wed, 23 Jan 2013 23:15:57 +0400 Subject: [PATCH] Add AArch64 (64-bit ARM) target support * include/private/gcconfig.h (AARCH64): New macro (defined only if __aarch64__). * include/private/gcconfig.h (mach_type_known): Update comment adding ARM AArch64 target. * include/private/gcconfig.h (NOSYS, mach_type_known, CPP_WORDSZ, MACH_TYPE, ALIGNMENT, HBLKSIZE, OS_TYPE, LINUX_STACKBOTTOM, DYNAMIC_LOADING, DATASTART, DATAEND, STACKBOTTOM): Define for AArch64. --- include/private/gcconfig.h | 37 + 1 file changed, 37 insertions(+) --- a/src/racket/gc/include/private/gcconfig.h +++ b/src/racket/gc/include/private/gcconfig.h @@ -76,6 +76,13 @@ # endif /* Determine the machine type: */ +# if defined(__aarch64__) +#define AARCH64 +#if !defined(LINUX) +# define NOSYS +# define mach_type_known +#endif +# endif # if defined(__arm__) || defined(__thumb__) #define ARM32 #if !defined(LINUX) !defined(NETBSD) !defined(OPENBSD) @@ -249,6 +256,10 @@ #define IA64 #define mach_type_known # endif +# if defined(LINUX) defined(__aarch64__) +#define AARCH64 +#define mach_type_known +# endif # if defined(LINUX) defined(__arm__) #define ARM32 #define mach_type_known @@ -529,6 +540,7 @@ /* running Amdahl UTS4 */ /* S390 == 390-like machine */ /* running LINUX */ + /* AARCH64== ARM AArch64 */ /* ARM32 == Intel StrongARM */ /* IA64 == Intel IPF */ /*(e.g. Itanium)*/ @@ -1818,6 +1830,31 @@ # endif # endif +# ifdef AARCH64 +# define CPP_WORDSZ 64 +# define MACH_TYPE AARCH64 +# define ALIGNMENT 8 +# ifndef HBLKSIZE +# define HBLKSIZE 4096 +# endif +# ifdef LINUX +# define OS_TYPE LINUX +# define LINUX_STACKBOTTOM +# define DYNAMIC_LOADING + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern char _end[]; +# define DATAEND ((ptr_t)(_end)) +# endif +# ifdef NOSYS + /* __data_start is usually defined in the target linker script. */ + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern void *__stack_base__; +# define STACKBOTTOM ((ptr_t)__stack_base__) +# endif +# endif + # ifdef ARM32 # define CPP_WORDSZ 32 # define MACH_TYPE ARM32 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Racket sometimes fails on openbsd/i386. The person who is in charge of the openbsd i386 packages has seen similar problems since the first day. My usual tricks to build racket is increase the datasize (-d), the number of open files (-n) and the stack size (-s). I only use one job in raco. In contrast to the i386 experience, racket works like a charm on openbsd/amd64. Sincerely, I don't know if the bug is in racket or in openbsd. On 12/29/2014 02:41 PM, Philippe Meunier wrote: Juan Francisco Cantero Hurtado wrote: Works fine on my machine. I've re-built the whole thing several times over the past few days and it does not fail every time. It has failed once out of the last three builds I did. Try with ulimit -d 100. My limit was already set at 1048576 :-) The racket process never reaches that size anyway. Here are two graphs showing the size of the process over time, for two different successful builds: http://www.ccs.neu.edu/home/meunier/chart1.pdf http://www.ccs.neu.edu/home/meunier/chart2.pdf There's one data point every second. The top and right edges of the graphs are the 1048576 KB limit. The maximum size reached (in the second build) was 900116 KB. Interestingly, even tough these two builds succeeded and finished normally, I noticed that they both gave this error message: raco setup: rendering: pkgs/images-doc/images/scribblings/images.scrbl unmap failed: 814000, 278528, 22 raco setup: rendering: pkgs/racket-doc/scribblings/inside/inside.scrbl In both builds the racket process was about 630 MB in size at the time this error message showed up. The place where this error message showed up is the exact same place in the build where racket failed in my original email... Now here is a graph for a build that failed: http://www.ccs.neu.edu/home/meunier/chart3.pdf It failed again while processing images.scrbl, but during the running part of the build this time, not the rendering part: raco setup: running: pkgs/images-doc/images/scribblings/images.scrbl Seg fault (internal error during gc) at 0xd98004 *** Signal SIGABRT in . (Makefile:62 'plain-in-place') *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place') The running: pkgs/.../images.scrbl is always the point in the build where the racket process reaches its maximum size (883864 KB in this case), but the process was already back down to about 584 MB when the internal error during gc message showed up. Here is the backtrace from gdb on the core file: (gdb) bt #0 0x04a78b01 in kill () at stdin:2 #1 0x04ae37f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x04ae3740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #3 0x16e9fc3c in fault_handler () from /home/meunier/lang/racket.new/racket/bin/racket #4 signal handler called #5 memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:66 #6 0x16ea64b9 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket #7 0x16e7de1f in scheme_register_traversers () from /home/meunier/lang/racket.new/racket/bin/racket #8 0x16ea6b54 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #9 0x16ea6c5d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #10 0x16ea37a6 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket #11 0x16ea5df4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket #12 0x16ea83ca in GC_malloc_atomic () from /home/meunier/lang/racket.new/racket/bin/racket #13 0x16ce7649 in scheme_generate_alloc_retry () from /home/meunier/lang/racket.new/racket/bin/racket #14 0x00236c9b in ?? () #15 0x in ?? () _ Racket Developers list: http://lists.racket-lang.org/dev
