[Caml-list] Anyone using Benedikt Meurer's new ARM code generator?

[Caml-list] Anyone using Benedikt Meurer's new ARM code generator?

[Richard W.M. Jones]

We recently put bmeurer's new ARM backend into Fedora/ARM, and
generally it works well.

However (very very occasionally) I'm getting odd segfaults from
programs.  One example is in camomile 0.8.3 during compilation:

  ocamlopt.opt -noassert -I internal -I public -I toolslib -I . -o mappings/gen_mappings.opt bigarray.cmxa str.cmxa toolslib.cmxa mappings/gen_mappings.cmx
  cd mappings && ./gen_mappings.opt
  /bin/sh: line 1: 13996 Illegal instruction     ./gen_mappings.opt
  make: *** [mappings/cns11643.mar] Error 132

Another is in libguestfs (in the virt-sysprep program, but it seems to
be a problem in the generated bindings).  I'm not sure this is the
same problem as in camomile.

I'd just like to compare notes with anyone else using the new backend.

Rich.

-- 
Richard Jones
Red Hat

[Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Benedikt Meurer]

On May 15, 2012, at 19:11 , Richard W.M. Jones wrote:

Hey Rich,

> We recently put bmeurer's new ARM backend into Fedora/ARM, and
> generally it works well.
> 
> However (very very occasionally) I'm getting odd segfaults from
> programs.  One example is in camomile 0.8.3 during compilation:
> 
>  ocamlopt.opt -noassert -I internal -I public -I toolslib -I . -o mappings/gen_mappings.opt bigarray.cmxa str.cmxa toolslib.cmxa mappings/gen_mappings.cmx
>  cd mappings && ./gen_mappings.opt
>  /bin/sh: line 1: 13996 Illegal instruction     ./gen_mappings.opt
>  make: *** [mappings/cns11643.mar] Error 132
> 
> Another is in libguestfs (in the virt-sysprep program, but it seems to
> be a problem in the generated bindings).  I'm not sure this is the
> same problem as in camomile.
> 
> I'd just like to compare notes with anyone else using the new backend.

I haven't heard of any problems yet. Can you provide additional information, i.e. architecture (armel/armhf), platform, etc.?

> Rich.

Benedikt

[Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Richard W.M. Jones]

On Tue, May 15, 2012 at 07:31:41PM +0200, Benedikt Meurer wrote:
> 
> On May 15, 2012, at 19:11 , Richard W.M. Jones wrote:
> 
> Hey Rich,
> 
> > We recently put bmeurer's new ARM backend into Fedora/ARM, and
> > generally it works well.
> > 
> > However (very very occasionally) I'm getting odd segfaults from
> > programs.  One example is in camomile 0.8.3 during compilation:
> > 
> >  ocamlopt.opt -noassert -I internal -I public -I toolslib -I . -o mappings/gen_mappings.opt bigarray.cmxa str.cmxa toolslib.cmxa mappings/gen_mappings.cmx
> >  cd mappings && ./gen_mappings.opt
> >  /bin/sh: line 1: 13996 Illegal instruction     ./gen_mappings.opt
> >  make: *** [mappings/cns11643.mar] Error 132
> > 
> > Another is in libguestfs (in the virt-sysprep program, but it seems to
> > be a problem in the generated bindings).  I'm not sure this is the
> > same problem as in camomile.
> > 
> > I'd just like to compare notes with anyone else using the new backend.
> 
> I haven't heard of any problems yet. Can you provide additional information, i.e. architecture (armel/armhf), platform, etc.?

It's a trimslice, running what Fedora calls armv7hl.tegra.

I don't want to say this is a real bug yet, because I'm actually using
a version of your code which I backported onto 3.12.1 myself -- not
realizing there was already a tree you wrote that contained that.  In
any case I need to test again with the upstream OCaml from SVN
(why-oh-why doesn't OCaml use git!)

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Markus Mottl]

On Tue, May 15, 2012 at 1:34 PM, Richard W.M. Jones <rich@annexia.org> wrote:
> (why-oh-why doesn't OCaml use git!)

It would indeed be awesome if the OCaml team considered switching to a
modern, distributed VCS.  Both git and Mercurial are vastly superior
to SVN.  Conversion tools also make it trivial to switch.  This could
really boost community productivity for bug fixing and feature
proposals.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Joel Reymont]

http://github.com

This would allow for documentation, etc. to be kept online and edited easily.

It would also allow for documented and well-presented pull requests
with patches.

On Tue, May 15, 2012 at 7:10 PM, Markus Mottl <markus.mottl@gmail.com> wrote:
> On Tue, May 15, 2012 at 1:34 PM, Richard W.M. Jones <rich@annexia.org> wrote:
>> (why-oh-why doesn't OCaml use git!)
>
> It would indeed be awesome if the OCaml team considered switching to a
> modern, distributed VCS.  Both git and Mercurial are vastly superior
> to SVN.  Conversion tools also make it trivial to switch.  This could
> really boost community productivity for bug fixing and feature
> proposals.
>
> Regards,
> Markus
>
> --
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
--------------------------------------------------------------------------
AlgoKit: EasyLanguage trading strategies, on the server, w/ Rithmic R|API
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------

Re: [Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Richard W.M. Jones]

On Tue, May 15, 2012 at 07:28:27PM +0100, Joel Reymont wrote:
> http://github.com
> 
> This would allow for documentation, etc. to be kept online and edited easily.
> 
> It would also allow for documented and well-presented pull requests
> with patches.

TBH we switched libguestfs hosting to github about 5 months ago, and
I'm not too happy with it.  Pull requests turn into merges (ie.
non-linear history) which I particularly dislike.

But there are lots of git hosting places, including the option of
setting up git hosting at INRIA -- it's very easy to setup and
maintain.

That's not the point though.  The point is that git is just *far
better* than SVN.  And also (compared to other VCS), git won.  Let's
get over it.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Daniel Bünzli]

Le mardi, 15 mai 2012 à 21:05, Richard W.M. Jones a écrit :

> But there are lots of git hosting places, including the option of
> setting up git hosting at INRIA -- it's very easy to setup and
> maintain.


FWIW, I use cgit [1] here : http://erratique.ch/repos/ and I confirm it's easy to setup (cgi), maintain, and it's fast too.  

Having been right today into the terrible svn web interface of ocaml's repository I would also welcome such a change.  

That being said, I once worked on a project via git-svn (git help svn) and it worked like a charm. You may want to try that (and me aswell).  

Best,

Daniel

[1] http://hjemli.net/git/cgit/

Re: [Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Github is maybe not perfect, but it requires *zero* maintenance. Does the
INRIA team want to set up a git server, setup gitosis for managing users,
etc, respond to someone when there is a problem. Github won. Let's get over
it.


On Tue, May 15, 2012 at 3:05 PM, Richard W.M. Jones <rich@annexia.org>wrote:

> On Tue, May 15, 2012 at 07:28:27PM +0100, Joel Reymont wrote:
> > http://github.com
> >
> > This would allow for documentation, etc. to be kept online and edited
> easily.
> >
> > It would also allow for documented and well-presented pull requests
> > with patches.
>
> TBH we switched libguestfs hosting to github about 5 months ago, and
> I'm not too happy with it.  Pull requests turn into merges (ie.
> non-linear history) which I particularly dislike.
>
> But there are lots of git hosting places, including the option of
> setting up git hosting at INRIA -- it's very easy to setup and
> maintain.
>
> That's not the point though.  The point is that git is just *far
> better* than SVN.  And also (compared to other VCS), git won.  Let's
> get over it.
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 2118 bytes --]

Re: [Caml-list] Re: Anyone using Benedikt Meurer's new ARM code generator?

[Mehdi Dogguy]

On 15/05/12 21:33, Ashish Agarwal wrote:
> Github is maybe not perfect, but it requires *zero* maintenance.
> Does the INRIA team want to set up a git server, setup gitosis for
> managing users, etc, respond to someone when there is a problem.
> Github won. Let's get over it.
>

Seriously, what kind of maintenance a Git repository does require?
Just create a unix group, create a bare shared repo, and have fun.

Besides, they are already maintaining (somehow, dunno the details) an
svn repository. Maintaining a git repo isn't harder…

anyway, it is not said that they will switch to git anyway :) I'd be
happy if they do, but it is not my call. iirc, it has been considered
when they moved away from cvs and they didn't choose it. i'm not sure
how much the situation changed since then (for the core team).

-- 
Mehdi Dogguy

[Caml-list] segfault in camomile / gen_mappings.ml (was: Re: Anyone using Benedikt Meurer's new ARM code generator?)

[Richard W.M. Jones]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]


It's not going to be very helpful, but I found that applying the
following patch makes the segfault go away.

Which makes me think .. Does ARM have arbitrary limits on text or data
size?  Does alignment matter?  Are empty match cases handled as a
special case by either ocamlopt or the new code generator?

Rich.

-- 
Richard Jones
Red Hat

[-- Attachment #2: gen_mappings.ml.patch --]
[-- Type: text/x-diff, Size: 434 bytes --]

--- /tmp/camomile-0.8.3/mappings/gen_mappings.ml	2011-05-20 10:40:49.000000000 +0100
+++ mappings/gen_mappings.ml	2012-05-19 10:42:42.961692259 +0100
@@ -159,7 +159,8 @@
 	  | _ -> ())
       |	TW ->
 	  (match String.length enc with
-	    1 -> ()			(*ascii*)
+	    1 -> 
+              print_string ""; ()			(*ascii*)
 	  | 2 ->			(*CNS 11643 Plane 1*)
 	      let enc1 = Char.code enc.[0] in
 	      let enc2 = Char.code enc.[1] in

[Caml-list] Re: segfault in camomile / gen_mappings.ml (was: Re: Anyone using Benedikt Meurer's new ARM code generator?)

[Benedikt Meurer]

On May 19, 2012, at 11:46 , Richard W.M. Jones wrote:

> It's not going to be very helpful, but I found that applying the
> following patch makes the segfault go away.
> 
> Which makes me think .. Does ARM have arbitrary limits on text or data
> size?  Does alignment matter?  Are empty match cases handled as a
> special case by either ocamlopt or the new code generator?

There are a few constraints for ARM, but that shouldn't matter in this case. I wasn't able to have a closer look yet, maybe the weekend provides some spare time. Can you file a bug report and attach the information collected so far?

> Rich.

Benedikt

[Caml-list] Re: segfault in camomile / gen_mappings.ml (was: Re: Anyone using Benedikt Meurer's new ARM code generator?)

[Richard W.M. Jones]

On Thu, May 24, 2012 at 09:40:23PM +0200, Benedikt Meurer wrote:
> 
> On May 19, 2012, at 11:46 , Richard W.M. Jones wrote:
> 
> > It's not going to be very helpful, but I found that applying the
> > following patch makes the segfault go away.
> > 
> > Which makes me think .. Does ARM have arbitrary limits on text or data
> > size?  Does alignment matter?  Are empty match cases handled as a
> > special case by either ocamlopt or the new code generator?
>
> There are a few constraints for ARM, but that shouldn't matter in
> this case. I wasn't able to have a closer look yet, maybe the weekend
> provides some spare time. Can you file a bug report and attach the
> information collected so far?

I filed this bug report:

http://caml.inria.fr/mantis/view.php?id=5623

Rich.

-- 
Richard Jones
Red Hat