[Caml-list] ocamldebug and windows

[Caml-list] ocamldebug and windows

[Dmitry Bely]

I am just curious why ocamldebug cannot work in the native Win32
Ocaml. Having searched the mailing list archives, I found the following
Xavier Leroy's article

http://caml.inria.fr/archives/199903/msg00014.html

where he explains that two main problems are (1) absense of checkpointing
facilities and (2) absense of unix sockets equivalent.

Ocaml debugger normally implements checkpoins via fork() syscall, which is
not available under Win32. But why simply not to use
ReadProcessMemory()/WriteProcessMemory() Win32 API functions to
save/restore the process memory image? I think it should be relatively
easy (BTW Cygwin uses these functions in its fork() implementation).

As for Unix sockets, Win32 has almost the same thing: named pipes.

So maybe is time to bring ocamldebug to Win32? :-)

- Dmitry Bely


-------------------
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

Re: [Caml-list] ocamldebug and windows

[Xavier Leroy]

> I am just curious why ocamldebug cannot work in the native Win32
> Ocaml. Having searched the mailing list archives, I found the following
> Xavier Leroy's article
> 
> http://caml.inria.fr/archives/199903/msg00014.html
> 
> where he explains that two main problems are (1) absense of checkpointing
> facilities and (2) absense of unix sockets equivalent.
> 
> Ocaml debugger normally implements checkpoins via fork() syscall, which is
> not available under Win32. But why simply not to use
> ReadProcessMemory()/WriteProcessMemory() Win32 API functions to
> save/restore the process memory image?

You need a bit more than this: file and socket handles also need some
checkpointing (of the kind that fork() does on file descriptors in the
Unix world).

> I think it should be relatively
> easy (BTW Cygwin uses these functions in its fork() implementation).

Yes, and I've looked at the fork() implementation in Cygwin.  It's a
remarkable engineering feat, but not something that I'd call
"relatively easy" :-)

> As for Unix sockets, Win32 has almost the same thing: named pipes.

Agreed, this isn't a show-stopper.

> So maybe is time to bring ocamldebug to Win32? :-)

As soon as someone writes a decent process checkpointing library for
Win32 :-)

- Xavier Leroy
-------------------
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

Re: [Caml-list] ocamldebug and windows

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

>> Ocaml debugger normally implements checkpoins via fork() syscall, which is
>> not available under Win32. But why simply not to use
>> ReadProcessMemory()/WriteProcessMemory() Win32 API functions to
>> save/restore the process memory image?
>
> You need a bit more than this: file and socket handles also need some
> checkpointing (of the kind that fork() does on file descriptors in the
> Unix world).

Really? Correct me if I am wrong, but fork() should care of the proper
handle copying because it creates the new child process, that should be in
the same state. But I suggest to use the only process, just save/restore
its state somethere when needed. This way the memory dump seems to be
sufficient, no?

Excuse me if this discussion becomes off-topic. I just wish Ocaml success in
Win32 world :-)

- Dmitry Bely


-------------------
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

Re: [Caml-list] ocamldebug and windows

[Xavier Leroy]

> > You need a bit more than this: file and socket handles also need some
> > checkpointing (of the kind that fork() does on file descriptors in the
> > Unix world).
> 
> Really? Correct me if I am wrong, but fork() should care of the proper
> handle copying because it creates the new child process, that should be in
> the same state. But I suggest to use the only process, just save/restore
> its state somethere when needed. This way the memory dump seems to be
> sufficient, no?

I'm afraid not.  Consider the following program:

    time t1:  open file /tmp/foo, obtaining file handle #3 (for instance)
    time t2:  work on this file handle
    time t3:  close file handle
    time t4:

Assume we're at time t4, and want to go back to the checkpoint at time
t2.  With the solution you outline, file handle #3 is closed and
re-executing the code between t2 and t3 fails.

It is true that time-travel in the presence of I/O is, in general,
impossible.  (You can't "un-send" the network packets that were
already sent!)  However, I'd like it to work at least for programs
that read or write regular files, as in the example above.  Under
Unix, fork() gets us 90% there -- there is still an issue with the
reading/writing position being shared (not duplicated) between the
parent and child process, but we are considering hacks to work around
this.  

- Xavier Leroy
-------------------
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

Re: [Caml-list] ocamldebug and windows

[Nicolas Cannasse]

> It is true that time-travel in the presence of I/O is, in general,
> impossible.  (You can't "un-send" the network packets that were
> already sent!)  However, I'd like it to work at least for programs
> that read or write regular files, as in the example above.  Under
> Unix, fork() gets us 90% there -- there is still an issue with the
> reading/writing position being shared (not duplicated) between the
> parent and child process, but we are considering hacks to work around
> this.

Of course, backward program execution is really a great feature !
But what about simply having a debugger under Win32 without it ? That would
be far better than no debugger at all...
And perhaps that will motivate some *cool hackers* who will then work on the
checkpointing library you were talking about or equivalent solutions.

- Nicolas Cannasse

-------------------
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

Re: [Caml-list] ocamldebug and windows

[Chris Hecker]

[Due to the recent s/n and flaming, I feel it necessary to caveat the 
following mail: I'm not trying to flame, these are just questions about 
engineering tradeoffs, and I love ocaml and motherhood and apple pie (or 
tart tatin or whatever is patriotic in France, which actually happens to be 
my favorite country, but I digress!).]

>It is true that time-travel in the presence of I/O is, in general,
>impossible.  (You can't "un-send" the network packets that were
>already sent!)  However, I'd like it to work at least for programs
>that read or write regular files, as in the example above.  Under
>Unix, fork() gets us 90% there -- there is still an issue with the
>reading/writing position being shared (not duplicated) between the
>parent and child process, but we are considering hacks to work around
>this.

Is all of this really worth it when compared to having a cross-platform 
"normal" debugger, especially if that debugger architecture could work on 
native code as well?  In other words, it seems like we're giving up a lot 
for this time-traveling feature.  I've played with it a bit, and it seems 
fine, but the fact that it's central to the debugger architecture makes 
some other things harder (like porting it :).

What was the impetus for doing it?  I'd assume the person who wrote the 
debugger thought it was cool and/or had it as a research project, and so 
that's what got written.  Which is fine, I'm not really complaining, I'm 
just trying to understand it.

I was also surprised that the debugger couldn't eval and link in arbitrary 
ocaml code, especially since a) the debugger works only on bytecode, and b) 
caml already has a toplevel.

Has anyone looked at writing a debugging plugin for gdb or something?  My 
program can't run in bytecode because it's got feedback loops based on 
framerate, so I have to run in native.  It'd be nice to be able to debug 
above the _Unix__fun_1470 level.  It seems like the native code gc frames 
have a fair amount of information in them (values on the stack pointing to 
the heap), and you could augment that info for unboxed values on the stack, 
etc.

I don't know how easy it is to extend gdb, though.

Chris

-------------------
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

RE: [Caml-list] ocamldebug and windows

[Mattias Waldau]

The debugger is 40% of the reason I use ocaml. 
The other two reasons is typing 40%, and resonable speed 20%.

The debugger makes it possible to debug large programs, just litter 
the code with assert, run until assert fails and backstep.
(I spent a lot of time debugging VC++, and there you have to
run, put break point before, run again, move break point....)

Typing makes my program work when they compile.

Resonable speed makes it possible not to have the most complex
algorithms.

Since the debugger has problems under cygwin for larger programs 
(the debugger looses contact), I have even thought buying ibook or
powerbook, 
just to get the debugger work well on a laptop 
(linux and laptops: try getting wlan and acpi to work :-)

I only use the win32-version of ocaml before creating release versions
of 
the program, since cygwin cannot be shipped. (I haven't tried mingw)

/mattias

> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr 
> [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Chris Hecker
> Sent: Tuesday, October 22, 2002 5:57 PM
> To: Xavier Leroy; Dmitry Bely
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] ocamldebug and windows
> 
> 
> 
> [Due to the recent s/n and flaming, I feel it necessary to caveat the 
> following mail: I'm not trying to flame, these are just 
> questions about 
> engineering tradeoffs, and I love ocaml and motherhood and 
> apple pie (or 
> tart tatin or whatever is patriotic in France, which actually 
> happens to be 
> my favorite country, but I digress!).]
> 
> >It is true that time-travel in the presence of I/O is, in general, 
> >impossible.  (You can't "un-send" the network packets that 
> were already 
> >sent!)  However, I'd like it to work at least for programs 
> that read or 
> >write regular files, as in the example above.  Under Unix, 
> fork() gets 
> >us 90% there -- there is still an issue with the reading/writing 
> >position being shared (not duplicated) between the parent and child 
> >process, but we are considering hacks to work around this.
> 
> Is all of this really worth it when compared to having a 
> cross-platform 
> "normal" debugger, especially if that debugger architecture 
> could work on 
> native code as well?  In other words, it seems like we're 
> giving up a lot 
> for this time-traveling feature.  I've played with it a bit, 
> and it seems 
> fine, but the fact that it's central to the debugger 
> architecture makes 
> some other things harder (like porting it :).
> 
> What was the impetus for doing it?  I'd assume the person who 
> wrote the 
> debugger thought it was cool and/or had it as a research 
> project, and so 
> that's what got written.  Which is fine, I'm not really 
> complaining, I'm 
> just trying to understand it.
> 
> I was also surprised that the debugger couldn't eval and link 
> in arbitrary 
> ocaml code, especially since a) the debugger works only on 
> bytecode, and b) 
> caml already has a toplevel.
> 
> Has anyone looked at writing a debugging plugin for gdb or 
> something?  My 
> program can't run in bytecode because it's got feedback loops 
> based on 
> framerate, so I have to run in native.  It'd be nice to be 
> able to debug 
> above the _Unix__fun_1470 level.  It seems like the native 
> code gc frames 
> have a fair amount of information in them (values on the 
> stack pointing to 
> the heap), and you could augment that info for unboxed values 
> on the stack, 
> etc.
> 
> I don't know how easy it is to extend gdb, though.
> 
> Chris
> 
> -------------------
> 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

-------------------
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

Re: [Caml-list] ocamldebug and windows

[Pierre Weis]

Nothing profound, skip if you don't have time!

[...]
> (linux and laptops: try getting wlan and acpi to work :-)

My laptop Linux box has once been happily backuping my Ipaq PocketPC
(also running Linux of course) using adhoc mode wireless networking :)

My personal acpi is named emacs and works perfectly for any file in /etc :)

Anyhow, I agree with you that a Mac could be sometimes a lot
simpler. However, I hate my Mac when it suddenly ceases to work
properly: my feeling then is often that the OS is way more complex
and difficult to masterize than Linux...

Regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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

Re: [Caml-list] ocamldebug and windows

[Alessandro Baretta]

Chris Hecker wrote:
> 
> Is all of this really worth it when compared to having a cross-platform 
> "normal" debugger, especially if that debugger architecture could work 
> on native code as well?  In other words, it seems like we're giving up a 
> lot for this time-traveling feature.  I've played with it a bit, and it 
> seems fine, but the fact that it's central to the debugger architecture 
> makes some other things harder (like porting it :).

I think time travel is one of the bigger bonuses of working 
with O'Caml. I understand the need for a simple debugger 
that works in all situations, but time travel is something 
O'Caml cannot give up.

  I was also surprised that the debugger couldn't eval and 
link in
> arbitrary ocaml code, especially since a) the debugger works only on 
> bytecode, and b) caml already has a toplevel.

This surprises me, too. Often, I'd like to run functions 
manually when at a checkpoint, for the sake of printing 
complex data structures. I would be content to be able to 
invoke functions predefined in the executable being debugged.

Alex

-------------------
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