Browse thread
[Caml-list] Problem with using oo in dynamically loaded bytecode ocaml runtime
-
Tomasz Zielonka
- Tomasz Zielonka
- Tomasz Zielonka
- Gerd Stolpmann
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-01-27 (12:37) |
From: | Gerd Stolpmann <info@g...> |
Subject: | Re: [Caml-list] Problem with using oo in dynamically loaded bytecode ocaml runtime |
On 2002.01.27 02:35 Tomasz Zielonka wrote: > Hi > > Situation: > > I'm doing some integration of OCaml and PostgreSQL. PostgreSQL loads a > DSO which implements so called "procedural language call handler". > > I've built this DSO by ld-shared'ing libcamlrun.a with some additional C > .o files, .o with wrappers for callback'ed ocaml funs, .o with new > primitives and .o with ocaml bytecode. I also removed main.o from > libcamlrun. > > I linked bytecode files into .o with following command: > > ocamlc -g -custom -output-obj -o plocamlb_bytecode.o plocamlb_spi.cmo \ > plocamlb_mlfuns.cmo > > Problem: Everything worked fine until I wanted to define a class. I did this kind of linking, too, but I did not have any problems. (I am not loading into Postgresql, but into a Perl interpreter, but I think this does not make any difference.) I have used -output-obj for a long time, but recently (with the availability of O'Caml 3.04) I switched to loading the bytecode directly. The debug sections are not lost, and the Dynlink library works. I can quickly describe what I am doing: - build libocamlrun.so by compiling the code in the "byterun" directory with -fPIC, and linking everything with ld -shared (but not main.o) - build some special libraries as DSOs. With O'Caml 3.04, you can load them dynamically. - build stubs.so. This is the entry point, i.e. the Perl interpreter does ldopen("stubs.so"), and it depends on some libraries: libocamlrun.so, and the libraries of the embedding application so their symbols are visible here. The entry point creates the argv array, and puts into argv[0] the absolute path of the bytecode file. (argv[1] is NULL.) Finally, I am calling caml_main(argv). This will load the bytecode file, and start executing it. In O'Caml I only initialize everything, and register a lot of callbacks, so that caml_main will quickly return to its caller. - Compiling the ocaml part is tricky: * Create a bytecode executable * Name all required libraries ==> ocamlc -o bytecode lib1.cma lib2.cma ... main.cma This will fail, because ocamlc looks up all primitives of the libraries, but the symbols of the embedding application are missing! (IMHO, there should be a command-line switch for ocamlc turning this off.) As a workaround, I create a fake library libfake.so containing all missing symbols, and I call ocamlc this way: LD_PRELOAD=libfake.so ocamlc ... > When I define a class with _no methods_, it works, but there is little > use of such class. > > When I define any method in this class (but still don't use a single > instance of the class) it stops working. After loading the DSO, ocaml > raises Not_found exception and quits. > > I wanted to use CAMLRUNPARAM b (stack backtrace) option, but apparently > it doesn't work with such a library/DSO (Program not linked with -g, > cannot print stack backtrace). > > I couldn't force ocamlc to keep DBUG section. I'm not sure it would > help, because read_debug_info tries to open executable file, not the > loaded DSO. I tried several caml_main_param[0] (different files), no > luck. > > When I make native/opt library _and_ define a method, I get corrupted > memory in the postgresql backend. The generated code is not PIC, so it won't work. > So: > 1) There is a bug, but where? In my program, in OCaml? It is more likely that the bug is in your program. > 2) How to get stack backtrace in this situation? See my method. Stack backtraces work, even the debugger works if you name the socket explicitly. Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 45 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ---------------------------------------------------------------------------- ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr