On Thu, Aug 22, 2013 at 03:33:45PM -0600, Jerry James wrote:
On Wed, Aug 21, 2013 at 1:34 PM, Richard W.M. Jones rjones@redhat.com 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?
Yes, this would be a good idea ... I don't think it'll cause problems on non-x86. Worst case it would just produce non-functional debuginfo files there.
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).
I guess a missing emulation of this insn in valgrind, but I'll let people who know more about ARM answer that!
Rich.