DEBUG File Reference
Go to the source code of this file.
We suppose that you are able to run your program `PGM' with the svm runtime on a single host with something like
parXXLrun --np P --logfile - --run svm PGM -- ARGUMENTS
and that PGM *and all of parXXL* is compiled with debugging options. To do that you should add something like
to your make commandline. Do a `make clean' first and recompile everything. If this doesn't work because the loader (ld) doesn't find some weird symbols you never heard of, please see below for Missing symbols
To be able to run under a debugger we first have to get rid of the parXXLrun script. All what it does in an svm context is to provide the necessary shared libraries, not a big deal: you have to find the directory DIR where the shared libraries reside, typically this is something like
Obviously the exact path depends on the architecture.
should give you a hint where to look at.
Now having identified DIR you have to add DIR and DIR/svm to your
LD_LIBRARY_PATH. To test if that worked
PGM -p P -o - -- ARGUMENTS
where P and ARGUMENTS are the same as above.
Having done that you may launch the debugger
if you already have a core file that you want to connect to.
To run PGM under the debugger issue the following at the prompt of the debugger
where P and ARGUMENTS are the same as above. This should run your program and you may interrupt it, investigate its call stack(s), etc as for any other program. Happy debugging!
parXXL is a complex software that uses a lot of C++ templates. Often the compiler is clever enough to inline most of them, in particular when full optimization is on. But, when we want to debug the code we need all functions explicitly. This is why sometimes optimized code links well and the same code with debugging options doesn't.
Most commonly you will encounter this for a data-type that is a template of your own private class, e.g if you code has
and you use par::mem::chunk< toto > this might result in missing symbols when linking your executable. Simply place something like
in the `.cc' file where you instantiate your class toto. Never place such a thing in a `.h'. And please use the corresponding macros as they are defined in the parXXL sources to instantiate, the instantiation might be more complex that you imagine in the first place.
Unfortunately the naming of these macros in not yet normalized, please look them up.
Now if you encounter such a problem for data-types that are entirely parXXL such as
where none of the nested types in question are your own, we missed to include that instantiation somewhere. You should tell us about that, or, even better, send us a patch if you are able to figure out where in parXXL this instantiation is missing. But please, please, first do another check if *all* of your parXXL is really recompiled with the same compile options.
Definition in file DEBUG.