Caml source line numbers in custom executable

Caml source line numbers in custom executable

[Christopher Alexander Stein]

Hi,

I am building a custom unstripped ELF executable that contains
the Caml runtime. The executable is segfaulting in runtime GC
routines. Can someone suggest how to cross reference these
routines with the corresponding file and line numbers of the Caml
source code so that gcc can tell me where the executable is
segfaulting?

Thank you

Lex

ps: Damien, I have tried using ocamldebug. It looks like an
excellent tool. In particular, it's time travel features are
powerful. However, in this case, it's use is limited by its
disconnected socket-based implementation; the executable
segfaults and the debugger loses contact.

Re: [Caml-list] Caml source line numbers in custom executable

[Damien Doligez]

> I am building a custom unstripped ELF executable that contains
> the Caml runtime. The executable is segfaulting in runtime GC
> routines. Can someone suggest how to cross reference these
> routines with the corresponding file and line numbers of the Caml
> source code so that gcc can tell me where the executable is
> segfaulting?

The GC routines are not in your Caml source code.  And most of the
time, a crash in the GC is caused by a bug somewhere else that
destroys some pointer.

If you really want to know where the crash occurs in your program,
you should get a stack backtrace from the core dump, using normal
Unix tools.  If you want debug information (symbols) in a
ocamlopt-compiled program, you can build libasmrund.a (in the
asmrun directory of the Ocaml sources) and use it instead of
libasmrun.a.

Unfortunately, these techniques are usually not very useful in
finding the bug.


> ps: Damien, I have tried using ocamldebug. It looks like an
> excellent tool. In particular, it's time travel features are
> powerful. However, in this case, it's use is limited by its
> disconnected socket-based implementation; the executable
> segfaults and the debugger loses contact.

Usually, that doesn't prevent the debugger from working: you can
step back from a segfault.  And then you can attach a gcc to the
right process, and use it to debug at the C/assembly level.

-- Damien