From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA18845; Fri, 19 Mar 2004 15:39:10 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 PAA17757 for ; Fri, 19 Mar 2004 15:39:09 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2JEdcKW014196 for ; Fri, 19 Mar 2004 15:39:38 +0100 Received: from bourg.inria.fr (bourg.inria.fr [128.93.11.100]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA18476 for ; Fri, 19 Mar 2004 15:39:08 +0100 (MET) Received: from starynke by bourg.inria.fr with local (Exim 4.30) id 1B4L8w-0001QM-6d for caml-list@inria.fr; Fri, 19 Mar 2004 15:38:38 +0100 Date: Fri, 19 Mar 2004 15:38:38 +0100 To: caml-list@inria.fr Subject: [Caml-list] debugging a JIT compiler (from Ocaml bytecode to machine code [x86,etc...]) Message-ID: <20040319143838.GA5284@bourg.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Basile Starynkevitch X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; debugging:01 basile:01 basile:01 interprets:01 ocaml's:01 byterun:01 runtime:01 debugging:01 bug:01 debugger:01 ptrace:01 breakpoint:01 debugger:01 callbacks:01 bug:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 232 Dear All, As you might have noticed on my home page below, I coded (in C, using the GNU lightning library) a JIT translator (or compiler) which interprets Ocaml bytecode by translating it to machine code, using the GNU lightning library. You'll need the latest CVS version of lightning from http://savannah.gnu.org/projects/lightning The intended use should be to replace ocaml's byterun/interp.c with my jitinterp.c and recompile all the runtime. Details are given in my homepage below. **this program is coded but still buggy** so don't use it *yet* (except for helping me). Debugging such a machine code generating program is painful. All trivial tests (those under CVS in test/testinterp/) passes but a bug still remain, which causes a segmentation violation (later on... - not at the faulty JIT codepoint!). Currently, I debugged most of it using a mixture of following techniques (enabled only with the -DDEBUG flag). 1. the generated machine code can be disassembled 2. the JIT translator is able to write on a pipe, originally to a Ruby script (hence the JML_RBYPRINTF name in the C code). (you need a special startup.c to open this pipe) 3. a specific tiny debugger (using the ptrace system call) has been coded to st breakpoint appropriately (in the generated machine code). 4. I instrumented also the bytecode interpreter to print its stack and registers (ie bytecode program counter, stack pointer, accumulator, ...) and manually compare it with traces from my debugger. 5. the bytecode is expected to stay fixed (this is false for C callbacks). If it is freed, the generated code should be freed also (which should be easy to code, since most of the stuff is there). My problem is that all simple tests run ok, and the few tests that crash have to run a significant amount, so the trace files are huge. I suspect that only one or two bug remains, like e.g. a wrong return from the GC on allocation, which corrupt the (Caml) stack ... The problem is that I lack of simple programs to exhibit it, and that the bug don't appear on trivial samples. I probably won't have time to work on it in the next few weeks, but any insight or hint is helpful. If you happen to have small test programs which uses a small fraction of the standard library, it should help also. If you would be interested by a JIT ocamlrunj program (with speedup of at most a factor of 2 w.r.t. to ocamlrun), please tell. If as a researcher or hacker you happen to write interpreters from scratch for a new super-duper language, consider using GNU lightning, it is very interesting and provide good results (which considerably easier to code with than generating machine code directly). Regards. -- Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr Project cristal.inria.fr - phone +33 1 3963 5197 - mobile 6 8501 2359 http://cristal.inria.fr/~starynke --- all opinions are only mine ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners