DEBUG File Reference

Go to the source code of this file.


Detailed Description

How to debug a parXXL application

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
 DEBUG=1 QUIET=1 
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

 ${PARXXL}/par/lib/linux/gcc/x86_64/nocona
Obviously the exact path depends on the architecture.
 parXXLrun parXXLlibpath
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

 gdb PGM 
or
 gdb PGM COREFILE
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

 r -p P -o- -- ARGUMENTS
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!

Missing symbols

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

 class toto;
and you use par::mem::chunk< toto > this might result in missing symbols when linking your executable. Simply place something like
 INSTANTIATE_CHUNK(toto);
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

 ... undefined symbol par::mem::chunk<unsigned long long>::someThingWeird
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.


Generated on Tue Oct 13 22:03:13 2009 for parXXL by  doxygen 1.5.8