On Thu, Aug 08, 2013 at 04:16:49PM -0600, Jerry James wrote:
> Hello all,
>
> I am trying to track down a problem with the frama-c package. It runs
> normally on i386 and x86_64, but exits immediately with an unhandled
> exception on arm. It is written in ocaml, which makes debugging
> difficult.
[Sorry for the late response]
GDB should work fine. It certainly works for x86 OCaml programs.
There is a fairly simple relationship between OCaml module + function
names and the assembly function names exposed in the DWARF
information, with the only caveat being that multiple functions in a
single OCaml module are allowed to have the same name (each assembler
function will have a number after it, but they are not consecutive).
If you get that it's best to try to correlate the assembly output with
the function name. The situation recently improved greatly on x86,
now that the DWARF info contains source file+line#, but I don't know
if that happened for ARM.
OCaml doesn't have a 'main' function as such, but any top level code
in any module will be executed at load time. This makes debugging
without GDB a pain, but with GDB it's pretty simple. However I've
also seen crashes (back when the ppc64 backend had a codegen bug)
happen before entering the main OCaml code, and those can be a real
pain ...
A final caveat is stack overflows. These can happen if the source is
not tail recursive, but the stack on some architectures is larger than
on others (ie. you'd see a strange architectural difference). Often
you can "fix" these by raising the stack ulimit. In any case, if you
are encountering a stack overflow on ARM, then it's a bug that
upstream should fix by rewriting the code to be tail recursive or more
imperative.
> I tried running it under valgrind to see if I could get any
> clues, but valgrind says:
>
> disInstr(arm): unhandled instruction: 0xEEBA5BEF
> cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF)
> ==23036== valgrind: Unrecognised instruction at address 0x4f2d30.
> ==23036== at 0x4F2D30: caml_adjust_gc_speed (in
> /home/jamesjer/rpmbuild/BUILD/frama-c-Fluorine-20130601/bin/toplevel.opt)
>
> A gdb disassembly of the containing function shows that instruction as:
>
> 0x004f2d30 <+128>: vcvt.f64.s32 d5, d5, #1
>
> Is that a legal instruction? I'm wondering if I should file a bug against
> valgrind for not recognizing the instruction, or whether something in the
> toolchain is emitting an instruction that is not valid for all CPUs in the
> class Fedora supports.
This might be a problem with the new ARM code generator[a] (ie. an
OCaml compiler problem). Things to do would include:
(1) Getting a stack trace from GDB and try to correlate it back to
the source code.
(2) Trying to chop down the code to get the minimal program which
segfaults.
(3) Contacting Benedikt Meurer or caml-list about it, although it'd
be better if we had the results of (1)+(2) in hand before we did
this.
Rich.
[a] http://caml.inria.fr/mantis/print_bug_page.php?bug_id=5433
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
