[M3devel] Note on an obscure m3gdb/compiler interaction

Rodney M. Bates rodney.bates at wichita.edu
Wed Sep 12 21:48:00 CEST 2007

If you link in a library, all the code of the entire library is loaded
into your address space, and all the debug data is available to m3gdb,
even for modules in the library but not in the import/export closure of
the main program.  This means you can call procedures in such modules
from m3gdb commands.

However, there is initialization of global data that the compilers take
care of only for modules in the closure.  If you call something from m3gdb
that is in memory but not initialized, various bad things can happen.

As an example, you can always call RTTypeFP.FromFingerprint, because it
is in libm3core.  And this could be a useful thing to want to do during
a debug session (e.g., when debugging something involving pickles). But
if you do this when RTTypeFP is not in the closure, there will be a segment
fault while trying allocate a heap object of a type whose type definition
pointer in the global space of RTTypeFP is uninitialized.  Even the needed
type definition is present, but the needed pointer to it is not set up.

For now, the only workaround is add an IMPORT of the needed module to the
code and recompile, before trying the call from m3gdb.

Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
rodney.bates at wichita.edu

More information about the M3devel mailing list