I just tried to compile 7.8.352 on a new core i7 box running OSX 10.6 using 32-bit abi and the build fails because the pike generated crashes somewhere in the machine code generation.
I compiled using the following command line:
make CONFIGUREARGS="--with-abi=32"
The backtrace looks like this:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000004f 0x000c0227 in ia32_flush_instruction_cache (start=<value temporarily unavailable, due to optimizations>, len=55) at ia32.c:1047 1047 __asm__ __volatile__(".byte 0x0f\n" (gdb) bt #0 0x000c0227 in ia32_flush_instruction_cache (start=<value temporarily unavailable, due to optimizations>, len=55) at ia32.c:1047 #1 0x0012e61e in eval_low (n=0x838d78, print_error=1) at /Users/hww3/Downloads/Pike-v7.8.352/src/las.c:5241 #2 0x0000b48b in yyparse () at language.yacc:660 #3 0x000ee199 in f_compilation_compile (args=0) at /Users/hww3/Downloads/Pike-v7.8.352/src/program.c:8213 #4 0x0001697b in low_mega_apply (type=APPLY_LOW, args=0, arg1=0x831fb4, arg2=0x1) at apply_low.h:226 #5 0x000181cc in mega_apply (type=APPLY_LOW, args=0, arg1=0x831fb4, arg2=0x1) at /Users/hww3/Downloads/Pike-v7.8.352/src/interpret.c:2211 #6 0x000185b0 in apply (o=0x831fb4, fun=0x1ecfbf "compile", args=0) at /Users/hww3/Downloads/Pike-v7.8.352/src/interpret.c:2604 #7 0x000d939f in f_compilation_env_compile (args=1) at /Users/hww3/Downloads/Pike-v7.8.352/src/program.c:7828 #8 0x0001697b in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x831fdc, arg2=0x1) at apply_low.h:226 #9 0x000181cc in mega_apply (type=APPLY_LOW, args=1, arg1=0x831fdc, arg2=0x1) at /Users/hww3/Downloads/Pike-v7.8.352/src/interpret.c:2211 #10 0x00145d5c in f_compile (args=1) at /Users/hww3/Downloads/Pike-v7.8.352/src/builtin_functions.c:4229 #11 0x000c83ae in get_master () at /Users/hww3/Downloads/Pike-v7.8.352/src/object.c:643 #12 0x000c85bb in debug_master () at /Users/hww3/Downloads/Pike-v7.8.352/src/object.c:689 #13 0x000b61cc in load_pike_master () at /Users/hww3/Downloads/Pike-v7.8.352/src/pike_embed.c:468 #14 0x000022e8 in main (argc=1, argv=0xbffff804) at /Users/hww3/Downloads/Pike-v7.8.352/src/main.c:629
Of course, things work fine using 64 bit ABIs, but I have a need to use some libraries that are 32 bit only, which of course makes everything more complicated. I'm going to assume that it's not something I've done wrong, but please do let me know if my assumption is incorrect :)
Thanks in advance,
Bill
Of course, things work fine using 64 bit ABIs, /.../
Which is because we still don't have any machine code support for x86_64. As a workaround you can always disable it for i386 as well: ./configure --without-machine-code
Otherwise it looks like the following commit could be the answer to your trouble (ugly though it is, I have to say). It's present in 7.8.368.
commit 3925525 Author: Per Hedbor ph@opera.com Date: Fri Nov 13 14:47:21 2009 +0100
This avoids 100% crach rate on my 64bit workstation with a 32-bit userlevel runtime
Rev: src/code/ia32.c:1.51
diff --git a/src/code/ia32.c b/src/code/ia32.c index ca552f1..ea0c2c9 100644 --- a/src/code/ia32.c +++ b/src/code/ia32.c @@ -2,7 +2,7 @@ || This file is part of Pike. For copyright information see COPYRIGHT. || Pike is distributed under GPL, LGPL and MPL. See the file COPYING || for more information. -|| $Id: ia32.c,v 1.50 2008/11/19 21:37:34 mast Exp $ +|| $Id: ia32.c,v 1.51 2009/11/13 13:47:21 per Exp $ */
/* @@ -1040,7 +1040,7 @@ void ia32_flush_instruction_cache(void *start, size_t len) clflush [eax]; } #else /* USE_GCC_IA32_ASM_STYLE */ -#ifdef HAVE_ASM_CLFLUSH +#if 1 __asm__ __volatile__("clflush %0" :: "m" (*addr)); #else /* clflush (%eax) */
Wouldn't it be better to fix the HAVE_ASM_CLFLUSH test so that it actually works?
Yes, and also check why the fallback doesn't work, because it's probably not the presence of clflush that makes it fail that way. Either that, or officially dropping support for x86 without it. I've no idea how common it is.
Just wanted to confirm that the fix Per checked in does resolve the problem. It's strange, though that intel would include such an instruction on their core 2 processors but not in the i7s.
Bill
On Fri, 1 Apr 2011, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Yes, and also check why the fallback doesn't work, because it's probably not the presence of clflush that makes it fail that way. Either that, or officially dropping support for x86 without it. I've no idea how common it is.
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
H. William Welliver III
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum