caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jianzhou Zhao <jianzhou@seas.upenn.edu>
To: caml-list@yquem.inria.fr
Subject: When can we ignore CAMLparam and CAMLreturn?
Date: Mon, 25 Oct 2010 12:19:56 -0400	[thread overview]
Message-ID: <AANLkTimJyz6t66K0OPW7xHsr5og22HkSws46vZhv-P93@mail.gmail.com> (raw)

Hi All,

Here is the code from LLVM-OCaml bindings.

/////////////////
/* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */
CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args,
                                   LLVMExecutionEngineRef EE) {
 unsigned NumArgs;
 LLVMGenericValueRef Result, *GVArgs;
 unsigned I;

 NumArgs = Wosize_val(Args);
 GVArgs = (LLVMGenericValueRef*) malloc(NumArgs * sizeof(LLVMGenericValueRef));
 for (I = 0; I != NumArgs; ++I)
   GVArgs[I] = Genericvalue_val(Field(Args, I));

 Result = LLVMRunFunction(EE, F, NumArgs, GVArgs);

 free(GVArgs);
 return alloc_generic_value(Result);
}
////////////////////////

In this code,  GenericValue.t is an Ocaml value with custom_operations
(say finalizing, hashing, serializing or deserializing a C type) as
shown in the below.

////////////////////////////
 #define Genericvalue_val(v)  (*(LLVMGenericValueRef *)(Data_custom_val(v)))

 static void llvm_finalize_generic_value(value GenVal) {
   LLVMDisposeGenericValue(Genericvalue_val(GenVal));
 }

 static struct custom_operations generic_value_ops = {
   (char *) "LLVMGenericValue",
   llvm_finalize_generic_value,
   custom_compare_default,
   custom_hash_default,
   custom_serialize_default,
   custom_deserialize_default
 };

 static value alloc_generic_value(LLVMGenericValueRef Ref) {
   value Val = alloc_custom(&generic_value_ops,
sizeof(LLVMGenericValueRef), 0, 1);
   Genericvalue_val(Val) = Ref;
   return Val;
 }
 ////////////////////////////////////

The 'llvm_ee_run_function' does not protect the Args parameter by
CAMLparam with CAMLreturn. Is this safe in this case, because we
allocated a GVArgs? The Ocaml manual suggests to use CAMLparam for any
value parameters
(http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc140). In
the other LLVM bindings files, the code sometimes also ignores
CAMLparam and CAMLreturn if Caml "value" refers to unit or string. Is
it also safe? for example.

/* string -> lltype -> llmodule -> llvalue */
CAMLprim LLVMValueRef llvm_define_function(value Name, LLVMTypeRef Ty,
LLVMModuleRef M) {
   LLVMValueRef Fn = LLVMAddFunction(M, String_val(Name), Ty);
   LLVMAppendBasicBlockInContext(LLVMGetTypeContext(Ty), Fn, "entry");
   return Fn;
}

I have been working on extending this Ocaml bindings, but got some
inconsistent results at runtime. I used Valgrind to check my program,
it reports some invalid writes or reads in C overlapping with some
memory space managed by Ocaml, but the report is not detailed enough.
so I doubt if the binding code does any thing wrong. Is there any tool
to help analyzing if the code manages memory between C and OCaml
bindings correctly?

Thanks
-- 
Jianzhou



-- 
Jianzhou


             reply	other threads:[~2010-10-25 16:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25 16:19 Jianzhou Zhao [this message]
2010-10-26  0:52 ` [Caml-list] " Jacques Garrigue
2010-10-27  9:36   ` Goswin von Brederlow
2010-10-27 13:32     ` Jianzhou Zhao
2010-10-27 15:19       ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimJyz6t66K0OPW7xHsr5og22HkSws46vZhv-P93@mail.gmail.com \
    --to=jianzhou@seas.upenn.edu \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).