Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugging embedded Ocaml applications #4703

Closed
vicuna opened this issue Jan 26, 2009 · 13 comments
Closed

Debugging embedded Ocaml applications #4703

vicuna opened this issue Jan 26, 2009 · 13 comments

Comments

@vicuna
Copy link

vicuna commented Jan 26, 2009

Original bug ID: 4703
Reporter: @db4
Assigned to: @xclerc
Status: acknowledged (set by @xavierleroy on 2009-03-28T17:19:15Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.0
Category: tools (ocaml{lex,yacc,dep,debug,...})
Tags: patch
Monitored by: yziquel @glondu @jmeber matt @alainfrisch

Bug description

Ocaml now supports ocamldebug under Windows (also due to some my effort); that's quite good. But there is another feature that I am missing: ability to debug embedded Ocaml apps (initialized via caml_startup()). Seems that not only I - discussion with Alain Frish from Lexifi shows that Lexifi people would also be happy if it becomes possible.

So I dug into Ocaml sources and now I can say it's doable with not very much effort. Actually I already have working implementation (tell me if you like to see the patch). Initial idea was the following: to modify bytecode linker so that

ocamlc -g -output-obj -o foo.obj ...

also generates foo.cds (abbreviation: Caml debug & symbols), that is an ordinary bytecode file containing DBUG and SYMB sections. I also modified startup.c to allow debugger initialization in caml_startup_code(). Now then I run

ocamldebug foo.cds

ocamldebug sees there is no CODE section (minor change) and switches into loadingmode=manual. Then I start the debugged app, Ocaml runtime initializes, connects to ocamldebug and everything seems to be working.

So far so good, but there another part of Ocaml runtime where debug info is needed: uncatched exception stack backtrace. Normally Ocaml runtime searches OS path for the bytecode executable, loads debug info and reports backtrace. But now foo.cds is not related to the running process (e.g. Ocaml app can be packed into foo.dll which is loaded by bar.exe). How to locate it? Currently in my prof-of-the-concept implementation I just strip extension from the process executable name and add .cds extension (works under Linux and Windows).

Alain Frish thinks I should get rid of any additional .cds files and just pack DBUG section as .c data. Then ocamldebug loads debug info via additional command in the low-level communication protocol; as for backtraces I should just unpack the .c data.

Of course it's also doable but with much more efforts. All Ocaml debug info reading/writing is channel-oriented (starting from caml_getword/input_binary_int), so some sort of resizable memory buffer structure + primitives should be added. Plus ocamldebug would behave slightly differently. Compare

(ocd) run
Loading program... (...)
has no debugging info.

with

(ocd) run
Loading program...
Waiting for connection...(the socket is 127.0.0.1:11980)
has no debugging info.

"no debug info" status could be reported only after the connection with the debuggee is established. I am afraid that can confuse some existing IDEs (OcaIDE, Emacs mode, etc.)

So I would like to know your opinion. What is the best approach from your point of view that would allow to integrate the patch into the distribution?

File attachments

@vicuna
Copy link
Author

vicuna commented Mar 28, 2009

Comment author: @xavierleroy

My apologies for taking so long to reply: I read your message with interest when you posted it, then got sidetracked by a number of other things.

Globally, I like the approach you propose. It is certainly a much smaller change than trying to embed debug info in the C object file as Alain proposed. Moreover, I'm a bit nervous about putting lots of debug info as C initialized data in a C executable.

In the meantime, you probably had the opportunity to experiment more with your approach. Does it work well in practice? If you're happy with it, I'm willing to integrate this change in OCaml. Feel free to send a patch if you have one ready.

@vicuna
Copy link
Author

vicuna commented Apr 2, 2009

Comment author: @db4

OK, the patch is now sort of been finalized. I have implemented the backtrace support the following way:

  1. When Ocaml linker generates .cds (debug info) file it also stores its full path as a C initialized data.
  2. caml_startup() initializes the global caml_cds_name variable with that data.
  3. When backtrace machinery searches for a bytecode file it tries caml_cds_name full path first.
  4. If not found, caml_cds_name base name is searched in the current process' directory.
  5. If not found, caml_cds_name base name is searched in the path specified by CAML_SYMBOL_PATH environment variable.

As for stability/usability - well, it seems to work OK for me (on Win32 platform). I did my best to not break anything Unix-specific, but testing is probably needed. If someone decides to try this any feedback will be appreciated.

The patch is against Ocaml 3.11.

@vicuna
Copy link
Author

vicuna commented Apr 3, 2009

Comment author: @db4

Last minute change. Replace the previous patch with this one.

@vicuna
Copy link
Author

vicuna commented May 5, 2009

Comment author: @db4

Fixed a bug. Replace the previous patch with this one (embedded-caml-debug3.diff)

@vicuna
Copy link
Author

vicuna commented Jun 18, 2009

Comment author: @xclerc

Support for debugging of embedded applications has been committed in branch "release311".
It is quite similar to the proposed patch, except that the name of the cds file is not saved in
the executable. Instead, one should set the "CAML_DEBUG_FILE" environment variable
(name chosen to be consistent with the "CAML_DEBUG_SOCKET" variable) to point to the
aforementioned cds file.

@vicuna
Copy link
Author

vicuna commented Jun 20, 2009

Comment author: @db4

Thanks, but what is wrong with the name of cds file in the debug executable? Just as a hint when CAML_DEBUG_FILE is not set? I proposed that as Microsoft Visual C++ under Windows uses similar approach: the name of .pdb (debug info) is hard-coded into the executable and used when .pdb is not found in the same directory as the executable module.

Using only CAML_DEBUG_FILE is error-prone (you will realize that it is wrong set only when an uncaught exception happen)

@vicuna
Copy link
Author

vicuna commented Nov 23, 2010

Comment author: @alainfrisch

What's the status of this issue? It seems the feature has been implemented but is left undocumented (no mention of it in the manual).

@vicuna
Copy link
Author

vicuna commented Dec 12, 2011

Comment author: @alainfrisch

Shouldn't this entry be marked as fixed (and documented)?

@vicuna
Copy link
Author

vicuna commented Apr 23, 2012

Comment author: @xclerc

Here is a short note, after we reached consensus ; the support for embedded
debugging will be enhanced in the following way.

Besides the use of the "CAML_DEBUG_FILE" environment variable, we will
fallback to the name of the cds file as stored in the executable. Both names
will be interpreted relatively to the path of the executable. Finally, the
executable will refuse to run if there is a MD5 mismatch between itself and
the cds file.

I am in charge of implementing this.

@vicuna
Copy link
Author

vicuna commented Jun 13, 2012

Comment author: @alainfrisch

Any update on this front?

@vicuna
Copy link
Author

vicuna commented Jun 14, 2012

Comment author: @xclerc

I did not have very much time to work on this issue but,
as of today, I encountered no showstopper.

As this does not involve any semantic change, I think it
could be safely committed at any point in development.

@vicuna
Copy link
Author

vicuna commented Feb 20, 2017

Comment author: @xavierleroy

Un-assigning from xclerc

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants