next up previous
Next: Name Conflicts in Up: Notes on Using Previous: Memory Allocation

Debugging Foreign Code

NOTE: this section is highly machine dependent. The tricks described here are tested on SUN-3 and SUN-4. They might work on other BSD variants of Unix.

Debugging incrementally loaded executables is a bit more difficult than debugging normal executables. The oldest way of debugging (putting print statements in your code at critical points) of course still works. `Post-crash' debugging however is not possible. For adb/dbx to work they need (besides the core) the text segment and the symbol table. The symbol table lives somewhere on /tmp (called `/tmp/pl_ld_..._. ', where `...' is the process id and `.' is an additional number to make sure the temporary file is unique. The text segment lives partly in the core (the incremental loaded bit) and partly in the SWI-Prolog executable.

The only way to debug foreign language code using a debugger is by starting the debugger on the running core image. Dbx(1) can do this. First compile the source files to be debugged with the `-g ' option to include dbx debugging information. Then load them into SWI-Prolog. Now obtain the name of the current symbol table and the process id of Prolog. Then start dbx (or dbxtool) using

sun% dbx[tool] <symbol file> <pid>

Should this be done often then the following foreign predicate definition might help:

pl_dbx()
{ char *symbolfile = PL_query(PL_QUERY_SYMBOLFILE);
  char cmd[256];

  sprintf(cmd, "dbxtool %s %d &", symbolfile, getpid());
  if ( system(cmd) == 0 )
    PL_succeed;
  else
    PL_fail;
}

Register this predicate as dbx/0 using the following call in your initialisation function:

PL_register_foreign("dbx", 0, pl_dbx, 0);



Passani Luca
Tue Nov 14 08:58:33 MET 1995