On Wed, Aug 21, 2013 at 1:34 PM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > [Sorry for the late response] Sorry I didn't mention that I solved my problem already! > 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. Ah, yes, a useful debuginfo package is now generated on x86. That's nice. Is there any chance we could start throwing out all the stuff in the ocaml spec files that prevents debuginfo package generation? Or will that cause problems on non-x86 platforms? As for this bug, it did happen before entering the main OCaml code. By single stepping through assembly code (that was fun), I was able to eventually drop back down into OCaml code, which is where the problem turned out to be (in an initializer). Upstream produced a fix for me, and the package has already been rebuilt with that fix. But even though the code now runs fine and gdb can disassemble the function in question, valgrind still doesn't like that CPU instruction (which has nothing whatever to do with the actual bug, by the way). Thanks, Richard. -- Jerry James http://www.jamezone.org/ _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
