From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Zeffertt Subject: Re: caml stubdom crashes Date: Fri, 03 Apr 2009 09:53:12 +0100 Message-ID: <49D5CE78.30206@eu.citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "George S. Coker, II" Cc: Patrick Colp , xen-devel , Samuel Thibault List-Id: xen-devel@lists.xenproject.org George S. Coker, II wrote: > > > On 4/2/09 12:22 PM, "Patrick Colp" wrote: > >> Alex Zeffertt wrote: >>> Hello ocaml minios stubdomain experts (that's narrowed down the list >>> somewhat!) >>> >>> I've been playing with the caml version of the "hello world" example >>> stubdomain that can be found in xen-unstable.hg/stubdom/caml/. >>> >>> If I make the following trivial modification to stubdom/caml/hello.ml >>> the stub domain page faults. According to addr2line the page fault is >>> in ungetc.c:0. >>> >>> --- a/stubdom/caml/hello.ml Mon Mar 30 11:42:16 2009 +0100 >>> +++ b/stubdom/caml/hello.ml Thu Apr 02 15:15:45 2009 +0100 >>> @@ -1,4 +1,6 @@ >>> +let yr = 2009 >>> + >>> let main arg = >>> - Printf.printf "Hello, world!\n%!." >>> + Printf.printf "Hello, world %d!\n%!." yr >>> >>> let _ = Callback.register "main" main >>> >>> >>> Without the above change the stub domain runs as expected, i.e. it does >>> not page fault. >>> >>> I suspect the problem is that the caml-stubdom target in >>> stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with >>> $(CAMLLIB)/libasmrun.a. But this is a library compiled for the >>> development machine platform (linux-i386-glibc) not for the stubdomain >>> platform (minios-i386-newlib). >>> > > I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but > rather the FORTIFY compiler options that introduce the > __fprintf_chk/__sprintf_chk funcs. There is still something about the > behavior of the FORTIFY options that I am still not accounting for. As > Patrick points out, special ports of ocaml should not be (and have not been) > necessary. > Hi George, thanks for replying. Is this an option that was used when the ubuntu package managers built ocaml, but was not used by Debian. Or have I misunderstood. I'm using your "_chk and _fail canaries" patch (actually I've had to extend it as I got even more undefined syms when I tried to compile xen-ocaml-tools/xenstored.) Are you saying that there is a problem with this patch? Regards, Alex