From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 8CAA6BC6D for ; Tue, 5 Feb 2008 10:46:30 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGK/p0fAXQImh2dsb2JhbACCOjaNOgEBAQgKKZYlhXE X-IronPort-AV: E=Sophos;i="4.25,306,1199660400"; d="scan'208";a="7610024" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 10:46:30 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m159kRKv009214 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 5 Feb 2008 10:46:30 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAOq+p0dIDszqf2dsb2JhbACCOjaNOgEBCQQFCAoRBZYmhXE X-IronPort-AV: E=Sophos;i="4.25,306,1199660400"; d="scan'208";a="8763965" Received: from qb-out-0506.google.com ([72.14.204.234]) by mail3-smtp-sop.national.inria.fr with ESMTP; 05 Feb 2008 10:46:28 +0100 Received: by qb-out-0506.google.com with SMTP id a16so3214552qbd.11 for ; Tue, 05 Feb 2008 01:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=TnPiAs/UN04j2gnHZ4ooYQS/XYz/i5ESjIRBaixFnis=; b=wHGpFQ6DTtflEFwdeFGkEZSxZCjPiq9scVcfYxkKZ9Q15Nm7w+SJu1GjmaFjg7Bpk82HFLKViLErWAjpBEXIyc7LIgh+uaqPE+wrAgk/3hL1dF8u5hDZm+08C5C+dLLs2FI7PdqzXowwW7ZZr3sqtEvKrY3wVnPRDTDE7I3GZqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=mS3/QcjsPRZW8bu9zKtZE1I/0auD4C8YrG91yG1Golo/xi1eLhP3VOD8f0NFT+S3ae0Oa1nLDeSmjMxrZzz6ZIJ+dAW3HM8Ohs9/aB9Q/xJHoAbIznXq8CpAlv81V0HkO05Tj52B7FbZLqKrkr3wnIMeKe6tZib7R6PylUAW9mA= Received: by 10.110.42.13 with SMTP id p13mr3688382tip.19.1202204786278; Tue, 05 Feb 2008 01:46:26 -0800 (PST) Received: by 10.110.26.14 with HTTP; Tue, 5 Feb 2008 01:46:26 -0800 (PST) Message-ID: <90823c940802050146u7cac0aape4e72b4fc6a3089@mail.gmail.com> Date: Tue, 5 Feb 2008 12:46:26 +0300 From: "Dmitry Bely" To: ocaml Subject: Ocaml debugger under Windows MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22745_27439135.1202204786275" X-Miltered: at discorde with ID 47A83073.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 debugger:01 ocaml:01 mingw:01 ocam:01 debugger:01 byterun:01 ocamldebug:01 cygwin:01 cygwin:01 sockets:01 sockets:01 ocamldebug:01 usenix:01 mingw:01 ------=_Part_22745_27439135.1202204786275 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The topic has a long history [1], but since then nothing has actually changed. It's easy to understand: INRIA people are busy and there are probably quite few Ocaml users in the Windows land to worry about. So I decided to do something myself :) (as it was with mingw port several years ago). Let's go into detail. Ocam debugger consists of the the two parts: the client (byterun/debugger.c linked into debuggee) and the server (ocamldebug). The following issues should be addressed to make a Windows port: 1. Checkpointing is done via Unix fork() (client) The most problematic one. I have spend a fair amount of time trying to find an acceptable solution. a) direct port of fork() to Windows. There is a BSD-licenced Windows fork() in tcsh sources [2] that could be used. It's based on Cygwin ideas. But how to handle dynamically loaded DLLs (loaded via LoadLibrary())? I asked the author (Amol Deshpande) and he replied: "DLLs that are dynamically loaded are a can of worms. I would not support those if I were you." BTW, does Cygwin do this right? I doubt at least. b) some checkpoint library. Although Web search gives many references, e.g. [3], I have not found yet anything ready-to-use, even commercial! 2. Unix select (server) It is a problem because server waits for network and console events simultaneously. To work on Windows the main loop should probably be multi-threaded. 3. Unix sockets (client & server) Probably can be ignored. Internet sockets are quite enough. So what is done now. - Client It's ported without (1) and (3). To me it's quite usable even without checkpoints. - Server I don't bother to do (2) right now (until the whole idea is accepted). Currently I use cygwin-compiled ocamldebug with checkpoints and Unix sockets disabled by default. It works well with the native Win32 clients. - OcaIDE Yes, with minor changes in OcaIDE the debugged works there. If it's interesting for anyone I can publish a patch against Ocaml 3.10.1 - Dmitry Bely [1] http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbdee52ddf6fd91.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2002/10/ed776d7376ed7a9676d4a9981372ccdf.fr.html [2] http://www.tcsh.org/MostRecentRelease [3] http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_papers/srouji/srouji_html/srouji.html ------=_Part_22745_27439135.1202204786275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The topic has a long history [1], but since then nothing has actually changed. It's easy to understand: INRIA people are busy and there are probably quite few Ocaml users in the Windows land to worry about. So I decided to do something myself :) (as it was with mingw port several years ago).

Let's go into detail. Ocam debugger consists of the the two parts: the client (byterun/debugger.c linked into debuggee) and the server (ocamldebug). The following issues should be addressed to make a Windows port:

1. Checkpointing is done via Unix fork() (client)

The most problematic one. I have spend a fair amount of time trying to find an acceptable solution.
a) direct port of fork() to Windows. There is a BSD-licenced Windows fork() in tcsh sources [2] that could be used. It's based on Cygwin ideas. But how to handle dynamically loaded DLLs (loaded via LoadLibrary())? I asked the author (Amol Deshpande) and he replied:

"DLLs that are dynamically loaded are a can of worms. I would not support those if I were you."

BTW, does Cygwin do this right? I doubt at least.

b) some checkpoint library. Although Web search gives many references, e.g. [3], I have not found yet anything ready-to-use, even commercial!

2. Unix select (server)

It is a problem because server waits for network and console events simultaneously. To work on Windows the main loop should probably be multi-threaded.

3. Unix sockets (client & server)

Probably can be ignored. Internet sockets are quite enough.

So what is done now.

- Client

It's ported without (1) and (3). To me it's quite usable even without checkpoints.

- Server

I don't bother to do (2) right now (until the whole idea is accepted). Currently I use cygwin-compiled ocamldebug with checkpoints and Unix sockets disabled by default. It works well with the native Win32 clients.

- OcaIDE

Yes, with minor changes in OcaIDE the debugged works there.

If it's interesting for anyone I can publish a patch against Ocaml 3.10.1

- Dmitry Bely

[1] http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbdee52ddf6fd91.en.html
http://caml.inria.fr/pub/ml-archives/caml-list/2002/10/ed776d7376ed7a9676d4a9981372ccdf.fr.html

[2] http://www.tcsh.org/MostRecentRelease

[3] http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_papers/srouji/srouji_html/srouji.html
------=_Part_22745_27439135.1202204786275--