3 ms·
> - the memory representation of values is uniform and native code debugging with gdb/lldb works great, thanks to the DWARF symbols emitted. Besides being able
by ptc 12y ago
> - the memory representation of values is uniform and native code debugging with gdb/lldb works great, thanks to the DWARF symbols emitted.
Besides being able to get a simple backtrace, I've always had nothing but headaches trying to print out variables. It's not tightly integrated with gdb, so the default "p my_ocaml_var" of course doesn't work and info locals rarely if ever works. Only time the debugging is good is when you get to the C code underlying the system calls.
I would love for this not to be the case, but I'm not sure if anyone is working on making OCaml better to debug in gdb.
- avsm 12y ago> I'm not sure if anyone is working on making OCaml better to debug in gdb Mark Shinwell is working on just this; he has a very impressive branch of OCaml which can do OCaml-level source backtraces in gdb; WIP tree is here for anyone who wants to glance at the patches: https://github.com/mshinwell/ocaml/compare/ocaml:4.02...4.02-gdb https://github.com/mshinwell/ocaml/compare/ocaml:4.02...4.02... Also a nice talk from a couple of years ago by him on some tips and tricks for using gdb/OCaml: https://www.youtube.com/watch?v=NF2WpWnB-nk https://www.youtube.com/watch?v=NF2WpWnB-nk
- ptc 12y agoThanks for the links, I'll have to take a look at that gdb/OCaml debugging video. Might as well dive into the OCaml internals a bit too. I just really wish OCaml would move to a fully threaded execution model instead of forcing evented systems on everyone.