From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 82594BB9C for ; Wed, 16 Nov 2005 16:03:03 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jAGF3317011604 for ; Wed, 16 Nov 2005 16:03:03 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA21555 for ; Wed, 16 Nov 2005 16:03:02 +0100 (MET) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jAGF30ms012774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 16 Nov 2005 16:03:02 +0100 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1EcP8E-0003oA-00; Wed, 16 Nov 2005 15:23:30 +0000 Date: Wed, 16 Nov 2005 15:23:30 +0000 To: caml-list@inria.fr Cc: caml-bugs@pauillac.inria.fr Subject: THREADED_CODE: Why CODE32 defined on x86-64? Message-ID: <20051116152330.GA9895@furbychan.cocan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Richard Jones X-Miltered: at concorde with ID 437B4A27.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 437B4A24.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; pointers:01 bytecode:01 bytecode:01 segfaults:01 ocaml-:01 ocaml-:01 3.09.0:01 ostype:01 cygwin:01 gcc:01 gcc:01 esac:01 notepad:01 orig:01 define:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Why is CODE32 defined on the x86-64 architecture? This architecture has 64 bit pointers, and it seems like it's only by luck that the bytecode interpreter normally works. In particular, if you have the interpreter in a shared library, or (I assume) address-space randomization, then the jump table is located above the 4GB boundary, and the bytecode interpreter segfaults as soon as it tries to jump to the first instruction. I had to apply the following patch to allow the bytecode interpreter to work in a shared library: --- ocaml-3.09.0.orig/configure 2005-09-24 10:19:09.000000000 +0100 +++ ocaml-3.09.0/configure 2005-11-16 14:59:56.000000000 +0000 @@ -291,9 +291,7 @@ exe=".exe" ostype="Cygwin";; gcc*,x86_64-*-linux*) - bytecccompopts="-fno-defer-pop $gcc_warnings" - # Tell gcc that we can use 32-bit code addresses for threaded code - echo "#define ARCH_CODE32" >> m.h;; + bytecccompopts="-fno-defer-pop $gcc_warnings";; gcc*) bytecccompopts="-fno-defer-pop $gcc_warnings";; esac Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Team Notepad - intranets and extranets for business - http://team-notepad.com