The src/config.h and src/target.h header files attempt to obtain
as much information from the compiler as possible, mainly from any predefined
preprocessor macros that it defines during compilation. If this information
is incorrect then you can override the
macros defined in src/target.h to suit your particular system by
explicitly defining them in
CFLAGS within the Makefile when you
build mpatrol. You could also choose to build different versions of mpatrol
with different settings of
DYNLINK on a
single system if you wish to by changing
DYNLINK for different builds.
You will have to look at the documentation for the compiler you are using in
order to find out how to specify which operating environment you wish to
target. For example, if you are using the Sun C compiler on a SPARC V9 Solaris
machine then you should specify the -xarch=v9 option in the
Makefile when you are building mpatrol in order to target the 64-bit
environment. If you think that you are already using the correct option, but
the mpatrol code is still being built to support the wrong environment then you
could try explicitly setting the
ENVIRON preprocessor macro in the
The most likely reason that you are getting errors is because you are calling
new, and the way that mpatrol derives source information from
operator new is by defining a macro called
causing lots of problems when calling placement
new or explicitly
operator new. You can either try not to use placement
new or you can define the preprocessor macro
compiling your source file, which will disable the overriding of any C++
operators in mpatrol.h. Alternatively, if you define
MP_NONEWDELETE then you can use
MP_DELETE in order to call the mpatrol versions of the C++ operators.
newsince the compiler complains about
operator new, so could that be a clue?
Yes. The most likely reason is that the C++ compiler does not support the array
delete operators. These were introduced some time before
the standardisation of the C++ language but some compilers may not yet have
support for them. It may be that you have to use a special compiler option to
enable support for these operators, but if not you will probably have to edit
mpatrol.h to temporarily allow your files to compile.
Yes. The mpatrol.h header file defines new versions of the C++ dynamic
memory allocation operators using exceptions and namespaces as required by the
ANSI C++ standard. If your C++ compiler has no support for these then you
should compile your C++ source files with
MP_NOCPLUSPLUS defined. You
may also be using an older C++ library in which the new header file does
set_new_handler() to be in the
std namespace. You will
then have to change the mpatrol.h header file and cplus.c source
operator new(not the nothrow version) from my C++ source code but when my program runs out of memory the `OUTMEM' error is given in the mpatrol log file rather than throwing a
std::bad_allocexception. Why is this?
Sounds like the mpatrol library was built with a C compiler. In order for the
mpatrol versions of
operator new and
operator new to throw an
exception when they run out of memory, the mpatrol library must have been built
with a C++ compiler. The `OUTMEM' error is only given when there is no way
to throw an exception.
alloca()? I only ever seem to call the default version.
Most implementations of the
alloca() function are compiler builtins which
will be converted to inline assembler or object code in order for them to be
able to dynamically modify the calling function's stack frame at run-time. As
a result, the call to
alloca() is recognised as an intrinsic keyword and
is dealt with specially by the compiler. However, if this can be intercepted by
the preprocessor before the compiler parses the source code then the call can be
redirected to another function. This is one of the functions of the
mpatrol.h header file, which means that it must be included before the
first call the
alloca.h is also being included then
mpatrol.h must be included after it, otherwise it may redefine
alloca() back to the default version.
The -fno-inline-functions option is a gcc-specific option which instructs the compiler not to inline any functions. This is necessary on some platforms where function call stack traversal is supported, since function inlining may significantly alter the layout of a program's stack. Normally this option is only required when building the mpatrol library, but on some platforms function call stack traversal may not work properly unless this option (or equivalent) is used for all compiled code.
MP_ALIGNdefinition in mpatrol.h do?
It is a preprocessor macro function that is used to return the minimum alignment
in bytes required for a specified type at compile-time. It is used in the
MP_MALLOC family of functions to specify the required alignment of the
memory allocation that is to be used to store the specified type. Some
compilers provide a built-in function that can be used to determine the minimum
alignment of a type at compile-time. For all others, this macro makes use of
some structure trickery in combination with the
MP_INLINEdefinition in mpatrol.h do?
It is used in the definition of the debugging versions of the C++ operators in
mpatrol.h so that they are inlined correctly. We want to define the C++
operators so that they will be inlined in every source file that uses them and
also not clash with the versions defined in the mpatrol library or the standard
C++ library. Traditionally, this is done by defining them to be
static inline, which means that any non-inlined definition will be local
to each object file. An even better technique is available with the new C++
standard which allows
extern inline definitions, meaning that no
definition will be available if the function is not inlined. Unfortunately, if
optimisation is turned off in the compiler then no inlining will usually be
performed and so the definitions will be real functions. Luckily, on ELF
extern inline function definition will have a weak
visibility and so will not clash with library functions.
When the compiler is optimising it will invariably be performing inlining, in which case each inlined function will share the stack frame of its caller when it is called — the mpatrol library cannot detect this. In order to cope in both situations, the non-inlined case will contain the name of the C++ operator at the top of its stack, even though it will be removed in the inlined case.
The GUI support for the mptrace command is currently written to use
Motif and X Windows and so can only be built on systems with these libraries
and run on systems with an X server. This will most likely be possible only on
UNIX platforms. LessTif can be used instead of Motif if that is all that is
available on your system. The UNIX Makefile has a macro called
GUISUP which can be set to
false depending on
whether you wish to have GUI support or not. The default is
GUI support is automatically enabled on platforms that support it if the
configure script in pkg/auto is used.
This is done by default on most platforms when using the Makefiles in
the build directory. However, if for some reason that is not the case
then on UNIX platforms you will have to set the
false when compiling mptrace. You might need to do
this if your UNIX system does not have the correct header files and libraries
installed needed for GUI support. If you are using the configure script
in pkg/auto then GUI support will be automatically disabled on platforms
that do not support it, but you can force it to be disabled by using the