Man Linux: Main Page and Category List

NAME

       mono  -  Mono's ECMA-CLI native code generator (Just-in-Time and Ahead-
       of-Time)

SYNOPSIS

       mono [options] file [arguments...]

DESCRIPTION

       mono  is  a  runtime  implementation  of  the  ECMA   Common   Language
       Infrastructure.  This can be used to run ECMA and .NET applications.

       The runtime contains a native code generator that transforms the Common
       Intermediate Language into native code.

       The code generator can operate in two modes: just in  time  compilation
       (JIT)   or  ahead  of  time  compilation  (AOT).   Since  code  can  be
       dynamically loaded, the runtime environment  and  the  JIT  are  always
       present, even if code is compiled ahead of time.

       The  runtime  loads  the  specified  file  and  optionally  passes  the
       arguments to it.  The file is an ECMA assembly.  They typically have  a
       .exe or .dll extension.

       The  runtime  provides  a  number  of configuration options for running
       applications,  for  developing  and  debugging,  and  for  testing  and
       debugging the runtime itself.

PORTABILITY

       On  Unix-based  systems,  Mono  provides  a  mechanism  to  emulate the
       Windows-style file access, this includes providing a  case  insensitive
       view  of the file system, directory separator mapping (from \ to /) and
       stripping the drive letters.

       This functionality is enabled by  setting  the  MONO_IOMAP  environment
       variable to one of all, drive and case.

       See the description for MONO_IOMAP in the environment variables section
       for more details.

RUNTIME OPTIONS

       The following options are available:

       --aot, --aot[=options]
              This option is used to precompile the CIL code in the  specified
              assembly to native code.  The generated code is stored in a file
              with the extension .so.  This file will be automatically  picked
              up  by the runtime when the assembly is executed.  Ahead-of-Time
              compilation is most useful if you use it in combination with the
              -O=all,-shared  flag  which  enables all of the optimizations in
              the code generator to be performed.  Some of those optimizations
              are  not practical for Just-in-Time compilation since they might
              be very time consuming.  Unlike the  .NET  Framework,  Ahead-of-
              Time  compilation  will not generate domain independent code: it
              generates the same code that  the  Just-in-Time  compiler  would
              produce.    Since most applications use a single domain, this is
              fine.   If you want to optimize the generated code  for  use  in
              multi-domain  applications,  consider  using the -O=shared flag.
              This pre-compiles the methods,  but  the  original  assembly  is
              still  required to execute as this one contains the metadata and
              exception information which is not available  on  the  generated
              file.   When  precompiling  code, you might want to compile with
              all  optimizations  (-O=all).   Pre-compiled  code  is  position
              independent code.  Pre compilation is just a mechanism to reduce
              startup  time,  increase  code  sharing  across  multiple   mono
              processes  and  avoid  just-in-time  compilation program startup
              costs.  The original assembly must  still  be  present,  as  the
              metadata  is  contained  there.   AOT  code typically can not be
              moved from one computer to another  (CPU-specific  optimizations
              that  are detected at runtime) so you should not try to move the
              pre-generated assemblies or package the pre-generated assemblies
              for  deployment.   A few options are available as a parameter to
              the --aot command line option.   The options  are  separated  by
              commas, and more than one can be specified:

              bind-to-runtime-version
                     If  specified, forces the generated AOT files to be bound
                     to the runtime version of the compiling Mono.   This will
                     prevent  the AOT files from being consumed by a different
                     Mono runtime.  full This  is  currently  an  experimental
                     feature  as  it  is not complete.  This instructs Mono to
                     precompile  code   that   has   historically   not   been
                     precompiled with AOT.

              outfile=[filename]
                     Instructs  the  AOT  compiler  to  save the output to the
                     specified file.

              write-symbols
                     Instructs  the  AOT  compiler  to   emit   debug   symbol
                     information.

              save-temps,keep-temps
                     Instructs the AOT compiler to keep temporary files.

              threads=[number]
                     This  is  an  experimental option for the AOT compiler to
                     use multiple threads when compiling the methods.

              nodebug
                     Instructs the AOT compiler to not  output  any  debugging
                     information.

              ntrampolines=[number]
                     When  compiling  in full aot mode, the method trampolines
                     must be  precreated  in  the  AOT  image.   You  can  add
                     additional   method   trampolines   with  this  argument.
                     Defaults to 1024.

              nrgctx-trampolines=[number]
                     When compiling in full  aot  mode,  the  generic  sharing
                     trampolines must be precreated in the AOT image.  You can
                     add additional method  trampolines  with  this  argument.
                     Defaults to 1024.

              nimt-trampolines=[number]
                     When compiling in full aot mode, the IMT trampolines must
                     be precreated in the AOT image.  You can  add  additional
                     method  trampolines with this argument.  Defaults to 128.

              print-skipped-methods
                     If the AOT compiler  cannot  compile  a  method  for  any
                     reason,  enabling  this  flag  will  output  the  skipped
                     methods to the console.

              autoreg
                     The  AOT  compiler  will  emit  a  (ELF   only)   library
                     initializer  to  automatically  register the aot compiled
                     module with the runtime.  This is only useful  in  static
                     mode

              asmonly
                     Instructs  the  AOT  compiler  to  output  assembly  code
                     instead of an object file.

              soft-debug
                     This instructs the compiler to  generate  sequence  point
                     checks   that   allow   Mono's  soft  debugger  to  debug
                     applications even on systems where it is not possible  to
                     set  breakpoints  or  to  single  step  (certain hardware
                     configurations like the  cell  phones  and  video  gaming
                     consoles).

              static Create  an  ELF  object file (.o) which can be statically
                     linked  into  an  executable  when  embedding  the   mono
                     runtime.  When this option is used, the object file needs
                     to be registered with  the  embedded  runtime  using  the
                     mono_aot_register_module  function  which  takes  as  its
                     argument the mono_aot_module_<ASSEMBLY NAME>_info  global
                     symbol from the object file:

                     extern void *mono_aot_module_hello_info;

                     mono_aot_register_module (mono_aot_module_hello_info);

              For   more   information   about   AOT,   see:  http://www.mono-
              project.com/AOT

       --attach=[options]
              Currently  the  only  option  supported  by  this  command  line
              argument is disable which disables the attach functionality.

       --full-aot
              This  is an experimental flag that instructs the Mono runtime to
              not generate any code at runtime and depend exclusively  on  the
              code  generated from using mono --aot=full previously.   This is
              useful for platforms that do not permit dynamic code generation.
              Notice  that  this  feature will abort execution at runtime if a
              codepath in your program, or Mono's class libraries attempts  to
              generate  code  dynamically.   You  should  test  your  software
              upfront and make sure that you do not use any dynamic  features.

       --config filename
              Load  the  specified  configuration  file instead of the default
              one(s).    The   default   files   are   /etc/mono/config    and
              ~/.mono/config   or   the  file  specified  in  the  MONO_CONFIG
              environment variable, if set.  See the mono-config(5)  man  page
              for details on the format of this file.

       --desktop
              Configures  the  virtual machine to be better suited for desktop
              applications.  Currently  this  sets  the  GC  system  to  avoid
              expanding the heap as much as possible at the expense of slowing
              down garbage collection a bit.

       --help, -h
              Displays usage instructions.

       --optimize=MODE, -O=MODE
              MODE is a comma separated  list  of  optimizations.   They  also
              allow   optimizations   to   be  turned  off  by  prefixing  the
              optimization name with a minus sign.  In general, Mono has  been
              tuned  to use the default set of flags, before using these flags
              for a deployment setting, you might want to actually measure the
              benefits   of  using  them.   The  following  optimizations  are
              implemented:
                           all        Turn on all optimizations
                           peephole   Peephole postpass
                           branch     Branch optimizations
                           inline     Inline method calls
                           cfold      Constant folding
                           consprop   Constant propagation
                           copyprop   Copy propagation
                           deadce     Dead code elimination
                           linears    Linear scan global reg allocation
                           cmov       Conditional moves [arch-dependency]
                           shared     Emit per-domain code
                           sched      Instruction scheduling
                           intrins    Intrinsic method implementations
                           tailc      Tail recursion and tail calls
                           loop       Loop related optimizations
                           fcmov      Fast x86 FP compares [arch-dependency]
                           leaf       Leaf procedures optimizations
                           aot        Usage of Ahead Of Time compiled code
                           precomp    Precompile all methods before executing Main
                           abcrem     Array bound checks removal
                           ssapre     SSA based Partial Redundancy Elimination
                           sse2       SSE2 instructions on x86 [arch-dependency]
                           gshared    Enable generic code sharing.
              For example, to  enable  all  the  optimization  but  dead  code
              elimination and inlining, you can use:
                   -O=all,-deadce,-inline
              The  flags that are flagged with [arch-dependency] indicate that
              the given option if used  in  combination  with  Ahead  of  Time
              compilation  (--aot  flag)  would produce pre-compiled code that
              will depend on the current CPU and might not be safely moved  to
              another computer.

       --runtime=VERSION
              Mono  supports  different  runtime  versions.  The  version used
              depends on the program that is being run or on its configuration
              file  (named  program.exe.config).  This  option  can be used to
              override such autodetection,  by  forcing  a  different  runtime
              version to be used. Note that this should only be used to select
              a later compatible runtime version than the one the program  was
              compiled  against.  A typical usage is for running a 1.1 program
              on a 2.0 version:
                       mono --runtime=v2.0.50727 program.exe

       --security, --security=mode
              Activate the security manager, a currently experimental  feature
              in  Mono  and it is OFF by default. The new code verifier can be
              enabled with this option as well.

              Using security without parameters is equivalent  as  calling  it
              with the "cas" parameter.

              The following modes are supported:

              cas    This   allows   mono   to  support  declarative  security
                     attributes, e.g. execution of Code Access Security  (CAS)
                     or non-CAS demands.

              core-clr
                     Enables  the core-clr security system, typically used for
                     Moonlight/Silverlight applications.  It provides  a  much
                     simpler  security  system  than CAS, see http://www.mono-
                     project.com/Moonlight for more details and links  to  the
                     descriptions of this new system.

              validil
                     Enables  the new verifier and performs basic verification
                     for  code  validity.   In  this  mode,  unsafe  code  and
                     P/Invoke  are allowed. This mode provides a better safety
                     guarantee but it is still possible for  managed  code  to
                     crash Mono.

              verifiable
                     Enables  the  new verifier and performs full verification
                     of the code being executed.  It  only  allows  verifiable
                     code  to  be  executed.   Unsafe  code is not allowed but
                     P/Invoke is.  This mode should not allow managed code  to
                     crash  mono.   The  verification is not as strict as ECMA
                     335 standard in order to  stay  compatible  with  the  MS
                     runtime.

              The  security  system  acts  on  user  code:  code  contained in
              mscorlib or the global assembly cache is always trusted.

       --server
              Configures the virtual machine to be better  suited  for  server
              operations (currently, a no-op).

       --verify-all
              Verifies  mscorlib  and  assemblies in the global assembly cache
              for valid IL, and all user code for IL verifiability.

              This is different from --security's  verifiable  or  validil  in
              that  these  options  only check user code and skip mscorlib and
              assemblies located on the global assembly cache.

       -V, --version
              Prints JIT version information  (system  configuration,  release
              number and branch names if available).

DEVELOPMENT OPTIONS

       The  following  options  are  used  to  help  when  developing  a JITed
       application.

       --debug, --debug=OPTIONS
              Turns on the debugging mode in the runtime.  If an assembly  was
              compiled with debugging information, it will produce line number
              information for stack traces.

              The optional OPTIONS argument  is  a  comma  separated  list  of
              debugging  options.   These  options  are  turned off by default
              since they generate much larger and slower code at runtime.

              The following options are supported:

              casts  Produces   a   detailed    error    when    throwing    a
                     InvalidCastException.    This  option needs to be enabled
                     as this generates more verbose code at execution time.

              mdb-optimizations
                     Disable some JIT optimizations  which  are  usually  only
                     disabled  when  running inside the debugger.  This can be
                     helpful if you want to attach to the running process with
                     mdb.

              gdb    Generate  and  register  debugging  information with gdb.
                     This is only supported on some platforms, and  only  when
                     using gdb 7.0 or later.

       --profile[=profiler[:profiler_args]]
              Turns  on  profiling.   For  more  information  about  profiling
              applications and code coverage see the sections "PROFILING"  and
              "CODE COVERAGE" below.

       --trace[=expression]
              Shows  method names as they are invoked.  By default all methods
              are traced.  The trace can be customized to include  or  exclude
              methods,  classes  or assemblies.  A trace expression is a comma
              separated list of targets, each target can be  prefixed  with  a
              minus   sign  to  turn  off  a  particular  target.   The  words
              `program', `all' and `disabled' have special meaning.  `program'
              refers  to  the main program being executed, and `all' means all
              the method calls.  The `disabled' option is  used  to  start  up
              with  tracing  disabled.   It can be enabled at a later point in
              time in the  program  by  sending  the  SIGUSR2  signal  to  the
              runtime.   Assemblies  are specified by their name, for example,
              to trace all calls in the System assembly, use:

                   mono --trace=System app.exe

              Classes are specified with the T: prefix.  For example, to trace
              all calls to the System.String class, use:

                   mono --trace=T:System.String app.exe

              And  individual  methods  are referenced with the M: prefix, and
              the standard method notation:

                   mono --trace=M:System.Console:WriteLine app.exe

              As previously noted, various rules can be specified at once:

                   mono --trace=T:System.String,T:System.Random app.exe

              You can  exclude  pieces,  the  next  example  traces  calls  to
              System.String except for the System.String:Concat method.

                   mono --trace=T:System.String,-M:System.String:Concat

              Finally, namespaces can be specified using the N: prefix:

                   mono --trace=N:System.Xml

       --no-x86-stack-align
              Don't  align  stack frames on the x86 architecture.  By default,
              Mono aligns stack frames to 16  bytes  on  x86,  so  that  local
              floating point and SIMD variables can be properly aligned.  This
              option  turns  off  the  alignment,  which  usually  saves   one
              intruction  per  call,  but  might result in significantly lower
              floating point and SIMD performance.

JIT MAINTAINER OPTIONS

       The maintainer options are only used by those  developing  the  runtime
       itself, and not typically of interest to runtime users or developers.

       --break method
              Inserts  a  breakpoint  before the method whose name is `method'
              (namespace.class:methodname).  Use  `Main'  as  method  name  to
              insert a breakpoint on the application's main method.

       --breakonex
              Inserts  a  breakpoint  on exceptions.  This allows you to debug
              your application with a native debugger  when  an  exception  is
              thrown.

       --compile name
              This compiles a method (namespace.name:methodname), this is used
              for testing the compiler performance or to examine the output of
              the code generator.

       --compileall
              Compiles  all  the methods in an assembly.  This is used to test
              the compiler performance or to examine the output  of  the  code
              generator

       --graph=TYPE METHOD
              This  generates  a postscript file with a graph with the details
              about the specified  method  (namespace.name:methodname).   This
              requires  `dot'  and  ghostview  to  be  installed  (it  expects
              Ghostview  to  be  called  "gv").   The  following  graphs   are
              available:
                        cfg        Control Flow Graph (CFG)
                        dtree      Dominator Tree
                        code       CFG showing code
                        ssa        CFG showing code after SSA translation
                        optcode    CFG showing code after IR optimizations
              Some  graphs will only be available if certain optimizations are
              turned on.

       --ncompile
              Instruct the runtime on the number  of  times  that  the  method
              specified  by  --compile  (or all the methods if --compileall is
              used) to be  compiled.   This  is  used  for  testing  the  code
              generator performance.

       --stats
              Displays  information  about the work done by the runtime during
              the execution of an application.

       --wapi=hps|semdel
              Perform maintenance of the process  shared  data.   semdel  will
              delete  the  global semaphore.  hps will list the currently used
              handles.

       -v, --verbose
              Increases the verbosity level, each time it is listed, increases
              the  verbosity level to include more information (including, for
              example,  a  disassembly  of  the  native  code  produced,  code
              selector info etc.).

ATTACH SUPPORT

       The  Mono  runtime  allows  external  processes  to attach to a running
       process and load assemblies into the running program.    To  attach  to
       the  process,  a special protocol is implemented in the Mono.Management
       assembly.

       With this support it is possible to load assemblies that have an  entry
       point  (they  are  created  with  -target:exe  or -target:winexe) to be
       loaded and executed in the Mono process.

       The code is loaded into the root domain, and it starts execution on the
       special  runtime  attach  thread.    The attached program should create
       its own threads and return after invocation.

       This support allows for example debugging applications  by  having  the
       csharp shell attach to running processes.

PROFILING

       The  mono  runtime  includes  a  profiler  that  can be used to explore
       various performance related problems in your application.  The profiler
       is activated by passing the --profile command line argument to the Mono
       runtime, the format is:

            --profile[=profiler[:profiler_args]]

       Mono has a built-in profiler called 'default' (and is also the  default
       if  no  arguments  are  specified),  but  developers  can  write custom
       profilers, see the section "CUSTOM PROFILERS" for more details.

       If a profiler is not specified, the  default  profiler  is  used.   The
       profiler_args is a profiler-specific string of options for the profiler
       itself.  The default profiler accepts the following options 'alloc'  to
       profile  memory  consumption  by the application; 'time' to profile the
       time spent on each routine; 'jit' to collect time  spent  JIT-compiling
       methods  and  'stat'  to  perform  sample statistical profiling.  If no
       options are provided the default is 'alloc,time,jit'.

       By default the profile data is printed to stdout: to change  this,  use
       the  'file=filename'  option  to  output  the  data  to  filename.  For
       example:

            mono --profile program.exe

       That will run the program with the default profiler and  will  do  time
       and allocation profiling.

            mono --profile=default:stat,alloc,file=prof.out program.exe

       Will  do   sample  statistical  profiling  and  allocation profiling on
       program.exe. The profile data  is  put  in  prof.out.   Note  that  the
       statistical  profiler  has  a  very  low  overhead  and  should  be the
       preferred profiler to use (for better output use the full path  to  the
       mono binary when running and make sure you have installed the addr2line
       utility that comes from the binutils package).

LOGGING PROFILER

       The logging profiler is a general purpose profiler that can track  many
       different  kinds  of  events  and logs those into a file as the program
       executes.   This is different than previous profilers in Mono that kept
       the  information  in  memory and rendered a summary of the results when
       the program shut down.

       Using the  logging  profiler  means  that  useful  information  can  be
       gathered  for  long-running  applications,  applications that terminate
       abormally (crashes, segfaults, complicated tear down processes) or when
       no data about the shutdown is required.

       The  data  collected by the running threads is kept independent of each
       other to minimize the runtime overhead and the information dumped  into
       the log at regular intervals.

       A sample use is very simple:
            $ mono --profile=logging program.exe

            $ mprof-decoder program.mprof

       In  the  above example the logging profiler is used in its default mode
       that merely records GC statistics for  the  execution  of  program.exe.
       The  profiling data collected is stored in the file program.mprof.  The
       mprof-decoder tool is then used to analyze the data.

       You can instruct the logging profiler to record different one  or  more
       sets of events.   These are the modes supported:

              Statistical  Profiling (stat) the program instruction pointer is
              periodically sampled to determine where the program is  spending
              most  of its time.   Statistical profiling has a very low impact
              on a running application and it is very useful to get a  general
              picture of where time is being spent on a program.

              If  call chains are requested, for each sample the profiler gets
              a partial stack trace (limited by the specified depth)  so  that
              caller-callee information is available.

              Instrumenting:  each  method  enter  and  exit  is logged with a
              timestamp; further processing of the data can show  the  methods
              that  took  the  longer to execute, with complete accounting for
              callers and callees. However, this way of  profiling  is  rather
              intrusive and slows down the application significantly.

              Allocation: each allocation is logged.

              Allocation summary: shows, for each collection, a summary of the
              heap contents broken down by class (for each class the number of
              allocated  and  released  objects  is given, together with their
              aggregated size in bytes).

              Heap snapshot mode: dumps  the  whole  heap  contents  at  every
              collection  (or  at  user  specified  collections).  It  is also
              possible to request  a  collection  and  snapshot  dump  with  a
              signal.

       Moreover,  other  events  can be logged and analyzed, like jit time for
       each method, load and unload for assemblies, modules and and individual
       classes, and appdomain and thread creation and destruction.

       This  profiler is activated passing the --profile=logging option to the
       mono  runtime,  and  is  controlled  attaching  further  options,  like
       --profile=logging:statistical for doing statistical profiling (multiple
       options are separated by commas).

       As a quick primer, here are a few examples of  the  most  common  usage
       modes:

       To perform statistical profiling:

            mono --profile=logging:stat program.exe

       To perform statistical profiling, inspecting call chains up to depth 8:

            mono --profile=logging:stat=8 program.exe

       To profile allocations (by default the call stack will be analized  for
       each   allocation,   producing   detailed   caller  method  attribution
       infornation):

            mono --profile=logging:allocations program.exe

       To profile garbage collection activity at a high level (collection time
       and  objects  freed at each collection for each class are reported, but
       heap snapshots are not saved to disk):

            mono --profile=logging:allocations-summary program.exe

       To perform heap profiling taking heap snapshots:

            mono --profile=logging:heap=all program.exe

       To write the resulting data to a different file:

            mono --profile=logging:output=mydata.mprof program.exe

       Then you would need to  invoke  the  decoder  mprof-decoder(1)  on  the
       output  file to see the profiling results, or to examine heap snapshots
       and allocations in detail mprof-heap-viewer(1).

       The operating modes described above  are  the  default  ones,  and  are
       sufficient to use the profiler.

       To  further  customize  the  profiler  behavior there are more options,
       described below.

       These options can be individually enabled and disabled  prefixing  them
       with an (optional) '+' character or a '-' character.  For instance, the
       "allocations" option by default records also the  full  call  stack  at
       each  allocation.   If  only  the  caller  is  wanted,  one  should use
       "allocations,-save-allocation-stack",  or  to  disable  call   tracking
       completely  (making  the  profiler  less intrusive) "allocations,-save-
       allocation-caller,-save-allocation-stack".      In     practice     the
       "allocation"   option   by   default  behaves  like  "allocations,save-
       allocation-caller,save-allocation-stack", but the user can tune this to
       his needs.

       These are all the available options, organized by category:

       Execution profiling modes

              statistical, stat or s
                     Performs  statistical  profiling.   This is a lightweight
                     profiling mechanism and it has a much lower overhead than
                     the  enter-leave  profiling as it works by sampling where
                     the program is spending its time by using  a  timer.   If
                     specified with s=<number>, also inspect call chains up to
                     level <number>.

              enter-leave, calls or c
                     Measure the time spent inside each method call,  this  is
                     done  by  logging  the time when a method enters and when
                     the  method  leaves.   This  can  be  a  time   consuming
                     operation.

              jit, j Collect  information  about  time spent by the JIT engine
                     compiling methods.

       Allocation profiling modes

              allocations, alloc or a
                     Collect information about each allocation  (object  class
                     and   size).    By  default  this  also  implies  "+save-
                     allocation-caller" and "+save-allocation-stack".

              save-allocation-caller, sac
                     Save the direct caller of each allocation.  The  profiler
                     filters  out  wrapper methods, and also recognizes if the
                     allocation  has  been  performed  by  the  runtime  while
                     jitting a method.

              save-allocation-stack, sas
                     Save the full managed execution stack at each allocation.
                     While the "sac" option saves the direct caller, this  one
                     records  the  whole  stack  trace.  Note that in the call
                     stack the wrapper methods are not filtered  out.   Anyway
                     the  "sac"  and  "sas"  options  can be combined, and the
                     decoder will attribute  the  allocation  to  the  correct
                     method  even  if  the  wrapper is at the top of the stack
                     trace.

              allocations-summary or as
                     At each collection dump a summary of  the  heap  contents
                     (for  each  class,  the number and collective size of all
                     live and  freed  heap  objects).  This  very  lightweight
                     compared to full heap snapshots.

              unreachable, free or f
                     Performs  a lightweight profile of the garbage collector.
                     On each collection performed  by  the  GC,  the  list  of
                     unreachable  objects is recorded, and for each object the
                     class and size is provided.  This information can be used
                     to  compute  the heap size broken down by class (combined
                     with "a" can give the same information of "as",  but  the
                     log  file  contains  info  about  each individual object,
                     while in "as" the processing is done directly at  runtime
                     and the log file contains only the summarized data broken
                     down by class).

              gc or g
                     Measure the time spent in each collection, and also trace
                     heap resizes.

              heap-shot[=ARG], heap[=ARG] or h[=ARH]
                     Performs  full  heap  profiling.    In  this case on each
                     collection a full heap  snapshot  is  recorded  to  disk.
                     Inside  the  snapshots,  each  object  reference is still
                     represented so that it's possible to investigate  who  is
                     responsible for keeping objects alive.

              If  the  value  of  ARG is all, a heap snapshot is taken at each
              collection.

              If the value is an integer n, a snapshot will be  taken  at  the
              first n collections (like setting gcd=n );

              If  no additional argument is given to the heap option, the only
              way to take heap snapshots is to requeste them using the runtime
              socket  based  command  interface described below (see "Profiler
              activity control").

              Heap profiling also enables full allocation profiling (with call
              stacks), and each allocation can be related to its corresponding
              object in the snapshots, enabling investigations like "find  all
              objects  of  a given class allocated by a given method and still
              live  at  a  given  collection,  and  then  find   all   objects
              referencing them".

              This  kind  of  heap  snapshot  analysis  is performed using the
              mprof-heap-viewer(1) application.

              The number of heap snapshots taken (and the moment in which they
              are taken) can be further customized with the following options:

              gc-dumps=N, gc-d=N, gcd=N
                     states the number of snapshots that must be dumped (since
                     the  application starts).  Zero means no dumps at all, -1
                     means dump at all collections.

              These options exist because it can happen that the user wants to
              investigate
                     what happens during collections  but  without  forcing  a
                     collection using the command interface, because forcing a
                     collection alters the program behavior.  Of course it  is
                     possible  to  simply take a snapshot at every collection,
                     but in some workloads this is could not be feasible  (too
                     much  data).   So we have this "garbage collection dumps"
                     counter to control how many snapshots to take.

       Profiler activity control

              output=FILE, out=FILE or o=FILE
                     Use this option to provide the output file name  for  the
                     profile  log.   If  this option is not specified, it will
                     default to "<program-name>.mprof".

              output-suffix=SUFFIX, suffix=SUFFIX or os=SUFFIX: makes
                     the   output   file    name    equals    to    "<program-
                     name>-SUFFIX.mprof".

              start-enabled or se: start with the profiler active
                     (which is the default).

              start-disabled or sd: start with the profiler inactive.

              force-accurate-timer (or fac): the profiler by default uses
                     rtdsc to acquire timestamps for frequent events, but this
                     can be imprecise; using this option you force the use  of
                     "gettimeofday" at every event, which is more accurate but
                     much slower.

              command-port=port or cp=port (where port is an integer between
                     1024 nd 65535): Choose a TCP port where the profiler will
                     listen  for  user  commands.  The protocol is ASCII based
                     and  line  oriented  (one  line  per  command),  and  the
                     profiler  answers with one line containing either "OK" or
                     "ERROR" to each received command.

              The user can telnet to this port and give commands manually,  or
              a  GUI can use this facility to control the profiler at runtime.

              The available commands are:

              enable: Enables the profiler.

              disable: Disables the profiler.

              heap-snapshot: Takes a heap snapshot now (forces a full  garbage
              collection).

              heap-snapshot-counter=arg: Set the  counter  of  the  next  heap
              snapshots
                     that must be taken,  where  arg  can  be  "all"  (take  a
                     snapshot  at  every  collection),  "none"  (do  not  take
                     snapshots), or an integer "n" (take a heap  snapshot  for
                     the next "n" collections).

       Internal buffer sizes

              per-thread-buffer-size=N, tbs=N
                     Use  to specify the number of events that a thread buffer
                     can hold.   When the thread buffer is full, a  log  block
                     is written to disk.  This defaults to tbs=10000.

              statistical-thread-buffer-size=N, sbs=N
                     The number of statistical samples that are held in memory
                     before they are dumped to disk (the system  does  double-
                     buffering  and  the  statistical samples are written by a
                     helper thread, so the statistical  profiler  never  stops
                     and  is  able  to  profile  the  profiler  itself).  This
                     defaults to sbs=10000.

              write-buffer-size, wbs
                     Specifies  the  size  in  bytes  of  the  internal  write
                     buffers.  This defaults to wbs=1024.

       In its current state, this profiler can also perform heap analysis like
       the HeapShot profiler, but there is no UI to process this  information.

       Another  known  issue  is  that  if the timer is not strictly monotonic
       (like rtdsc), differences between times can underflow (they are handled
       as unsigned integers) and weird numbers can show up in the logs.

       Finally,  it  can  happen  that when exceptions are thrown the profiler
       temporarily loses track of the execution stack  and  misattributes  the
       caller for a few allocations (and method execution time).

       The  output  file  contains  compressed events, to process the data you
       should use tools like the "Mono.Profiler" tool provided on the Mono SVN
       repository.

       More     explanations     are    provided    here:    "http://www.mono-
       project.com/LoggingProfiler".

EXTERNAL PROFILERS

       There are a number of external profilers that have been  developed  for
       Mono, we will update this section to contain the profilers.

       The  heap  Shot  profiler can track all live objects, and references to
       these objects, and  includes  a  GUI  tool,  this  is  our  recommended
       profiler.  To install you must download the profiler from Mono's SVN:
            svn co svn://anonsvn.mono-project.com/source/trunk/heap-shot
            cd heap-shot
            ./autogen
            make
            make install

       See the included documentation for details on using it.

       The  Live  Type  profiler  shows  at every GC iteration all of the live
       objects of a given type.   To install you must  download  the  profiler
       from Mono's SVN:
            svn co svn://anonsvn.mono-project.com/source/trunk/heap-prof
            cd heap-prof
            ./autogen
            make
            make install

       To use the profiler, execute:
            mono --profile=desc-heap program.exe

       The output of this profiler looks like this:
            Checkpoint at 102 for heap-resize
               System.MonoType : 708
               System.Threading.Thread : 352
               System.String : 3230
               System.String[] : 104
               Gnome.ModuleInfo : 112
               System.Object[] : 160
               System.Collections.Hashtable : 96
               System.Int32[] : 212
               System.Collections.Hashtable+Slot[] : 296
               System.Globalization.CultureInfo : 108
               System.Globalization.NumberFormatInfo : 144

       The  first line describes the iteration number for the GC, in this case
       checkpoint 102.

       Then on each line the type is displayed as well as the number of  bytes
       that are being consumed by live instances of this object.

       The  AOT  profiler is used to feed back information to the AOT compiler
       about how to order code based on the access patterns for pages.  To use
       it, use:
            mono --profile=aot program.exe
       The  output of this profile can be fed back into Mono's AOT compiler to
       order the functions on the disk to produce precompiled images that have
       methods in sequential pages.

CUSTOM PROFILERS

       Mono  provides a mechanism for loading other profiling modules which in
       the form of shared libraries.  These profiling modules can hook  up  to
       various  parts of the Mono runtime to gather information about the code
       being executed.

       To use a third party profiler you must pass the name of the profiler to
       Mono, like this:

            mono --profile=custom program.exe

       In  the  above sample Mono will load the user defined profiler from the
       shared library `mono-profiler-custom.so'.  This profiler module must be
       on your dynamic linker library path.

       A list of other third party profilers is available from Mono's web site
       (www.mono-project.com/Performance_Tips)

       Custom profiles are written as shared libraries.   The  shared  library
       must be called `mono-profiler-NAME.so' where `NAME' is the name of your
       profiler.

       For a sample of how to write your own custom profiler look in the  Mono
       source tree for in the samples/profiler.c.

CODE COVERAGE

       Mono  ships  with  a code coverage module.  This module is activated by
       using   the   Mono    --profile=cov    option.     The    format    is:
       --profile=cov[:assembly-name[/namespace]] test-suite.exe

       By default code coverage will default to all the assemblies loaded, you
       can limit this by specifying the assembly name, for example to  perform
       code  coverage  in  the  routines  of your program use, for example the
       following command line limits the code  coverage  to  routines  in  the
       "demo" assembly:

            mono --profile=cov:demo demo.exe

       Notice that the assembly-name does not include the extension.

       You  can  further  restrict  the  code  coverage output by specifying a
       namespace:

            mono --profile=cov:demo/My.Utilities demo.exe

       Which will only  perform  code  coverage  in  the  given  assembly  and
       namespace.

       Typical output looks like this:

            Not covered: Class:.ctor ()
            Not covered: Class:A ()
            Not covered: Driver:.ctor ()
            Not covered: Driver:method ()
            Partial coverage: Driver:Main ()
                 offset 0x000a

       The offsets displayed are IL offsets.

       A  more  powerful  coverage  tool is available in the module `monocov'.
       See the monocov(1) man page for details.

DEBUGGING AIDS

       To debug managed applications, you can use the mdb command,  a  command
       line debugger.

       It  is  possible  to  obtain a stack trace of all the active threads in
       Mono by sending the QUIT signal to Mono,  you  can  do  this  from  the
       command line, like this:

            kill -QUIT pid

       Where  pid  is  the Process ID of the Mono process you want to examine.
       The process will continue running afterwards,  but  its  state  is  not
       guaranteed.

       Important:  this  is a last-resort mechanism for debugging applications
       and should not be used to monitor or probe  a  production  application.
       The  integrity  of  the  runtime  after  sending  this  signal  is  not
       guaranteed and the application might crash or terminate  at  any  given
       point afterwards.

       The  --debug=casts  option can be used to get more detailed information
       for Invalid Cast operations, it  will  provide  information  about  the
       types involved.

       You  can use the MONO_LOG_LEVEL and MONO_LOG_MASK environment variables
       to get verbose debugging output about the execution of your application
       within Mono.

       The  MONO_LOG_LEVEL  environment  variable if set, the logging level is
       changed to the set value.  Possible  values  are  "error",  "critical",
       "warning",  "message",  "info",  "debug". The default value is "error".
       Messages with a logging level greater then or equal to  the  log  level
       will be printed to stdout/stderr.

       Use "info" to track the dynamic loading of assemblies.

       Use  the  MONO_LOG_MASK environment variable to limit the extent of the
       messages you get: If set, the log mask is changed  to  the  set  value.
       Possible  values  are  "asm"  (assembly  loader), "type", "dll" (native
       library loader), "gc" (garbage collector), "cfg" (config file  loader),
       "aot"  (precompiler)  and  "all".  The default value is "all". Changing
       the mask value allows you  to  display  only  messages  for  a  certain
       component.  You  can  use  multiple masks by comma separating them. For
       example to see config file messages and assembly  loader  messages  set
       you mask to "asm,cfg".

       The following is a common use to track down problems with P/Invoke:

            $ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe

SERIALIZATION

       Mono's  XML serialization engine by default will use a reflection-based
       approach to serialize which might be  slow  for  continuous  processing
       (web  service  applications).   The serialization engine will determine
       when a class must use a hand-tuned serializer based on a few parameters
       and if needed it will produce a customized C# serializer for your types
       at runtime.  This customized serializer then  gets  dynamically  loaded
       into your application.

       You  can  control  this  with  the  MONO_XMLSERIALIZER_THS  environment
       variable.

       The possible values are `no' to disable the  use  of  a  C#  customized
       serializer, or an integer that is the minimum number of uses before the
       runtime will produce a custom  serializer  (0  will  produce  a  custom
       serializer  on  the  first  access, 50 will produce a serializer on the
       50th use). Mono will fallback  to  an  interpreted  serializer  if  the
       serializer  generation  somehow fails. This behavior can be disabled by
       setting      the      option      `nofallback'      (for       example:
       MONO_XMLSERIALIZER_THS=0,nofallback).

ENVIRONMENT VARIABLES

       GC_DONT_GC
              Turns  off  the garbage collection in Mono.  This should be only
              used for debugging purposes

       LVM_COUNT
              When Mono is compiled with  LLVM  support,  this  instructs  the
              runtime to stop using LLVM after the specified number of methods
              are JITed.  This is a tool used in diagnostics to  help  isolate
              problems   in   the   code  generation  backend.    For  example
              LLVM_COUNT=10 would only compile 10 methods with LLVM  and  then
              switch  to  the Mono JIT engine.  LLVM_COUNT=0 would disable the
              LLVM engine altogether.

       MONO_AOT_CACHE
              If set,  this  variable  will  instruct  Mono  to  ahead-of-time
              compile  new  assemblies  on  demand and store the result into a
              cache in ~/.mono/aot-cache.

       MONO_CFG_DIR
              If set, this variable overrides the default system configuration
              directory  ($PREFIX/etc).  It's  used  to  locate machine.config
              file.

       MONO_COM
              Sets the style of COM interop.  If the value of this variable is
              "MS"   Mono  will  use  string  marhsalling  routines  from  the
              liboleaut32 for the BSTR type library, any other values will use
              the mono-builtin BSTR string marshalling.

       MONO_CONFIG
              If   set,   this   variable   overrides   the   default  runtime
              configuration  file  ($PREFIX/etc/mono/config).   The   --config
              command line options overrides the environment variable.

       MONO_DEBUG
              If  set,  enables  some  features  of  the  runtime  useful  for
              debugging.  This variable should contain a comma separated  list
              of  debugging  options.   Currently,  the  following options are
              supported:

              break-on-unverified
                     If this variable is set, when the Mono  VM  runs  into  a
                     verification problem, instead of throwing an exception it
                     will break  into  the  debugger.   This  is  useful  when
                     debugging verifier problems

              collect-pagefault-stats
                     Collects  information  about  pagefaults.    This is used
                     internally to track the number of page faults produced to
                     load  metadata.  To display this information you must use
                     this option with "--stats" command line option.

              dont-free-domains
                     This is an Optimization for multi-AppDomain  applications
                     (most  commonly  ASP.NET  applications).  Due to internal
                     limitations Mono, Mono by  default  does  not  use  typed
                     allocations on multi-appDomain applications as they could
                     leak memory when a domain is unloaded.  Although this  is
                     a  fine  default,  for applications that use more than on
                     AppDomain heavily (for example, ASP.NET applications)  it
                     is  worth  trading  off the small leaks for the increased
                     performance (additionally, since ASP.NET applications are
                     not  likely  going  to  unload the application domains on
                     production systems, it is worth using this feature).

              handle-sigint
                     Captures the interrupt signal (Control-C) and displays  a
                     stack  trace  when pressed.  Useful to find out where the
                     program  is  executing  at  a  given  point.   This  only
                     displays the stack trace of a single thread.

              keep-delegates
                     This  option  will  leak delegate trampolines that are no
                     longer referenced  as  to  present  the  user  with  more
                     information   about   a  delegate  misuse.   Basically  a
                     delegate instance might be created, passed  to  unmanaged
                     code,  and no references kept in managed code, which will
                     garbage  collect  the  code.   With  this  option  it  is
                     possible to track down the source of the problems.

              no-gdb-backtrace
                     This option will disable the GDB backtrace emitted by the
                     runtime after a SIGSEGV or SIGABRT in unmanaged code.

              suspend-on-sigsegv

                     This option  will  suspend  the  program  when  a  native
                     SIGSEGV  is  received.   This  is  useful  for  debugging
                     crashes which do not  happen  under  gdb,  since  a  live
                     process contains more information than a core file.

       MONO_DISABLE_AIO
              If  set, tells mono NOT to attempt using native asynchronous I/O
              services. In that case, a default select/poll implementation  is
              used. Currently only epoll() is supported.

       MONO_DISABLE_MANAGED_COLLATION
              If   this  environment  variable  is  `yes',  the  runtime  uses
              unmanaged collation (which actually means  no  culture-sensitive
              collation).    It    internally   disables   managed   collation
              functionality     invoked      via      the      members      of
              System.Globalization.CompareInfo  class. Collation is enabled by
              default.

       MONO_EGD_SOCKET
              For platforms that do not otherwise  have  a  way  of  obtaining
              random bytes this can be set to the name of a file system socket
              on which an egd or prngd daemon is listening.

       MONO_EVENTLOG_TYPE
              Sets  the   type   of   event   log   provider   to   use   (for
              System.Diagnostics.EventLog).  Possible values are:

              local[:path]
                     Persists event logs and entries to the local file system.
                     The directory in which to persist the event  logs,  event
                     sources  and  entries  can  be  specified  as part of the
                     value.  If the path is not explicitly set, it defaults to
                     "/var/lib/mono/eventlog"        on        unix        and
                     "%APPDATA%no\ventlog" on Windows.

              win32  Uses the native win32 API to write events  and  registers
                     event  logs  and event sources in the registry.   This is
                     only  available  on  Windows.   On  Unix,  the  directory
                     permission  for  individual  event  log  and event source
                     directories is set to 777 (with +t bit) allowing everyone
                     to  read  and write event log entries while only allowing
                     entries to be deleted by the user(s) that created them.

              null   Silently discards any events.

              The default is "null" on Unix (and versions  of  Windows  before
              NT), and "win32" on Windows NT (and higher).

       MONO_EXTERNAL_ENCODINGS
              If set, contains a colon-separated list of text encodings to try
              when  turning  externally-generated  text   (e.g.   command-line
              arguments  or  filenames) into Unicode.  The encoding names come
              from  the  list  provided  by  iconv,  and  the   special   case
              "default_locale"  which  refers  to the current locale's default
              encoding.

              When reading externally-generated text strings  UTF-8  is  tried
              first,  and  then  this  list  is  tried in order with the first
              successful conversion ending the search.  When writing  external
              text  (e.g.  new  filenames  or  arguments to new processes) the
              first item in this list is used, or  UTF-8  if  the  environment
              variable is not set.

              The  problem  with using MONO_EXTERNAL_ENCODINGS to process your
              files is that it results in a problem: although its possible  to
              get  the  right file name it is not necessarily possible to open
              the file.  In general if you have  problems  with  encodings  in
              your filenames you should use the "convmv" program.

       MONO_GAC_PREFIX
              Provides  a  prefix the runtime uses to look for Global Assembly
              Caches.   Directories  are  separated  by  the   platform   path
              separator  (colons on unix). MONO_GAC_PREFIX should point to the
              top directory  of  a  prefixed  install.  Or  to  the  directory
              provided    in    the    gacutil   /gacdir   command.   Example:
              /home/username/.mono:/usr/local/mono/

       MONO_IOMAP
              Enables some filename rewriting support to assist  badly-written
              applications  that  hard-code  Windows  paths.   Set to a colon-
              separated list of "drive" to strip drive letters, or  "case"  to
              do  case-insensitive file matching in every directory in a path.
              "all" enables all rewriting methods.   (Backslashes  are  always
              mapped to slashes if this variable is set to a valid option.)
              For example, this would work from the shell:

                   MONO_IOMAP=drive:case
                   export MONO_IOMAP

              If you are using mod_mono to host your web applications, you can
              use the MonoIOMAP directive instead, like this:

                   MonoIOMAP <appalias> all

              See mod_mono(8) for more details.

       MONO_MANAGED_WATCHER
              If set to "disabled",  System.IO.FileSystemWatcher  will  use  a
              file  watcher  implementation  which  silently  ignores  all the
              watching   requests.    If   set    to    any    other    value,
              System.IO.FileSystemWatcher   will   use   the  default  managed
              implementation (slow). If unset, mono will try to  use  inotify,
              FAM,  Gamin,  kevent  under Unix systems and native API calls on
              Windows, falling back to the managed implementation on error.

       MONO_NO_SMP
              If set  causes  the  mono  process  to  be  bound  to  a  single
              processor.  This  may be useful when debugging or working around
              race conditions.

       MONO_PATH
              Provides a search path to the runtime where to look for  library
              files.    This  is a tool convenient for debugging applications,
              but should not be used by deployed applications as it breaks the
              assembly  loader  in  subtle ways.  Directories are separated by
              the  platform  path  separator  (colons   on   unix).   Example:
              /home/username/lib:/usr/local/mono/lib  Alternative solutions to
              MONO_PATH include: installing libraries into the Global Assembly
              Cache  (see  gacutil(1)) or having the dependent libraries side-
              by-side with the main executable.  For a complete description of
              recommended    practices   for   application   deployment,   see
              http://www.mono-project.com/Guidelines:Application_Deployment

       MONO_RTC
              Experimental RTC support in the  statistical  profiler:  if  the
              user  has the permission, more accurate statistics are gathered.
              The MONO_RTC value must be restricted  to  what  the  Linux  rtc
              allows:  power  of  two  from  64  to  8192 Hz. To enable higher
              frequencies like 4096 Hz, run as root:

                   echo 4096 > /proc/sys/dev/rtc/max-user-freq

              For example:

                   MONO_RTC=4096 mono --profiler=default:stat program.exe

       MONO_NO_TLS
              Disable inlining of thread local accesses. Try setting  this  if
              you get a segfault early on in the execution of mono.

       MONO_SHARED_DIR
              If  set  its  the  directory  where  the ".wapi" handle state is
              stored.  This is the directory where the Windows  I/O  Emulation
              layer  stores  its  shared  state  data (files, events, mutexes,
              pipes).  By default Mono will store the ".wapi" directory in the
              users's home directory.

       MONO_SHARED_HOSTNAME
              Uses  the string value of this variable as a replacement for the
              host name when creating file names  in  the  ".wapi"  directory.
              This  helps  if  the  host  name of your machine is likely to be
              changed when a mono application is running  or  if  you  have  a
              .wapi  directory shared among several different computers.  Mono
              typically uses the hostname to create the files that are used to
              share  state  across  multiple  Mono processes.  This is done to
              support home directories that might be shared over the  network.

       MONO_STRICT_IO_EMULATION
              If  set, extra checks are made during IO operations.  Currently,
              this includes only advisory locks around file writes.

       MONO_DISABLE_SHM
              If set, disables the shared memory files used for  cross-process
              handles:  process  have  only  private handles.  This means that
              process and thread handles are not available to other processes,
              and  named  mutexes,  named  events and named semaphores are not
              visible between processes.  This  is  can  also  be  enabled  by
              default  by  passing  the  "--disable-shared-handles"  option to
              configure.

       MONO_THEME
              The name of the theme to be used by  Windows.Forms.    Available
              themes  today  include  "clearlooks",  "nice"  and "win32".  The
              default is "win32".

       MONO_TLS_SESSION_CACHE_TIMEOUT
              The time, in seconds, that the SSL/TLS session cache  will  keep
              it's  entry  to avoid a new negotiation between the client and a
              server. Negotiation are very CPU intensive  so  an  application-
              specific  custom  value  may  prove  useful  for  small embedded
              systems.  The default is 180 seconds.

       MONO_THREADS_PER_CPU
              The maximum number of threads in the general threadpool will  be
              20  + (MONO_THREADS_PER_CPU * number of CPUs). The default value
              for this variable is 10.

       MONO_XMLSERIALIZER_THS
              Controls the threshold for the XmlSerializer to produce a custom
              serializer  for  a  given class instead of using the Reflection-
              based interpreter.  The possible values are `no' to disable  the
              use  of  a  custom  serializer  or a number to indicate when the
              XmlSerializer should start serializing.   The default  value  is
              50, which means that the a custom serializer will be produced on
              the 50th use.

       MONO_XMLSERIALIZER_DEBUG
              Set this value to 1 to prevent the serializer from removing  the
              temporary  files  that are created for fast serialization;  This
              might be useful when debugging.

       MONO_ASPNET_INHIBIT_SETTINGSMAP
              Mono contains a feature which allows modifying settings  in  the
              .config files shipped with Mono by using config section mappers.
              The  mappers  and  the  mapping  rules  are   defined   in   the
              $prefix/etc/mono/2.0/settings.map  file  and, optionally, in the
              settings.map file found  in  the  top-level  directory  of  your
              ASP.NET  application.   Both  files  are  read  by System.Web on
              application startup, if they are found at the  above  locations.
              If  you  don't want the mapping to be performed you can set this
              variable in your environment before starting the application and
              no action will be taken.

       MONO_MESSAGING_PROVIDER
              Mono   supports   a  plugin  model  for  its  implementation  of
              System.Messaging making it possible  to  support  a  variety  of
              messaging  implementations  (e.g.  AMQP,  ActiveMQ).  To specify
              which messaging implementation is to  be  used  the  evironement
              variable  needs  to  be  set  to  the  full  class  name for the
              provider.  E.g. to use the RabbitMQ  based  AMQP  implementation
              the variable should be set to:

              Mono.Messaging.RabbitMQ.RabbitMQMessagingProvider,Mono.Messaging.RabbitMQ

ENVIRONMENT VARIABLES FOR DEBUGGING

       MONO_ASPNET_NODELETE
              If set to any value, temporary source files generated by ASP.NET
              support classes will not be removed. They will be  kept  in  the
              user's temporary directory.

       MONO_LOG_LEVEL
              The  logging  level,  possible  values  are `error', `critical',
              `warning', `message', `info' and  `debug'.   See  the  DEBUGGING
              section for more details.

       MONO_LOG_MASK
              Controls  the domain of the Mono runtime that logging will apply
              to.  If set, the log mask is changed to the set value.  Possible
              values  are  "asm"  (assembly  loader),  "type",  "dll"  (native
              library loader), "gc" (garbage collector),  "cfg"  (config  file
              loader),  "aot"  (precompiler)  and "all".  The default value is
              "all". Changing the  mask  value  allows  you  to  display  only
              messages  for a certain component. You can use multiple masks by
              comma separating them. For example to see config  file  messages
              and assembly loader messages set you mask to "asm,cfg".

       MONO_TRACE
              Used  for  runtime  tracing  of  method calls. The format of the
              comma separated trace options is:

                   [-]M:method name
                   [-]N:namespace
                   [-]T:class name
                   [-]all
                   [-]program
                   disabled       Trace output off upon start.

              You can toggle trace output on/off sending a SIGUSR2  signal  to
              the program.

       MONO_TRACE_LISTENER
              If  set,  enables  the  System.Diagnostics.DefaultTraceListener,
              which will print the output of the System.Diagnostics Trace  and
              Debug  classes.  It can be set to a filename, and to Console.Out
              or  Console.Error  to  display  output  to  standard  output  or
              standard  error,  respectively.  If  it's  set to Console.Out or
              Console.Error you can append an optional  prefix  that  will  be
              used       when       writing      messages      like      this:
              Console.Error:MyProgramName.               See               the
              System.Diagnostics.DefaultTraceListener  documentation  for more
              information.

       MONO_XEXCEPTIONS
              This throws an exception when a X11  error  is  encountered;  by
              default a message is displayed but execution continues

       MONO_XSYNC
              This  is  used  in  the System.Windows.Forms implementation when
              running with the X11 backend.  This is used to debug problems in
              Windows.Forms  as  it  forces  all  of  the commands send to X11
              server to be done synchronously.   The default mode of operation
              is  asynchronous  which  makes  it  hard  to isolate the root of
              certain problems.

       MONO_GENERIC_SHARING
              This environment variable controls the kind of  generic  sharing
              used.   This  variable  is  used  by internal JIT developers and
              should not be changed  in  production.   Do  not  use  it.   The
              variable  controls  which classes will have generic code sharing
              enabled.  Permissible values are:

              all    All generated code can be shared.

              collections
                     Only the classes in System.Collections.Generic will  have
                     its code shared (this is the default value).

              corlib Only code in corlib will have its code shared.

              none   No generic code sharing will be performed.
       Generic code sharing by default only applies to collections.   The Mono
       JIT by default turns this on.

       MONO_XDEBUG
              When the the MONO_XDEBUG env var  is  set,  debugging  info  for
              JITted code is emitted into a shared library, loadable into gdb.
              This enables, for example, to see managed  frame  names  on  gdb
              backtraces.

       MONO_VERBOSE_METHOD
              Enables the maximum JIT verbosity for the specified method. This
              is very helpfull to diagnose  a  miscompilation  problems  of  a
              specific method.

VALGRIND

       If you want to use Valgrind, you will find the file `mono.supp' useful,
       it contains  the  suppressions  for  the  GC  which  trigger  incorrect
       warnings.  Use it like this:
           valgrind --suppressions=mono.supp mono ...

DTRACE

       On  some  platforms, Mono can expose a set of DTrace probes (also known
       as user-land statically defined, USDT Probes).

       They are defined in the file `mono.d'.

       ves-init-begin, ves-init-end
              Begin and end of runtime initialization.

       method-compile-begin, method-compile-end
              Begin and end of method compilation.  The  probe  arguments  are
              class  name,  method  name and signature, and in case of method-
              compile-end success or failure of compilation.

       gc-begin, gc-end
              Begin and end of Garbage Collection.

       To verify the availability of the probes, run:
                  dtrace -P mono'$target' -l -c mono

FILES

       On Unix assemblies are loaded from the installation lib directory.   If
       you  set  `prefix' to /usr, the assemblies will be located in /usr/lib.
       On Windows, the assemblies are loaded from the directory where mono and
       mint live.

       ~/.mono/aot-cache
              The  directory  for  the  ahead-of-time compiler demand creation
              assemblies are located.

       /etc/mono/config, ~/.mono/config
              Mono runtime configuration file.  See the mono-config(5)  manual
              page for more information.

       ~/.config/.mono/certs, /usr/share/.mono/certs
              Contains  Mono  certificate  stores for users / machine. See the
              certmgr(1)  manual  page  for  more  information   on   managing
              certificate  stores  and the mozroots(1) page for information on
              how to import  the  Mozilla  root  certificates  into  the  Mono
              certificate store.

       ~/.mono/assemblies/ASSEMBLY/ASSEMBLY.config
              Files   in   this  directory  allow  a  user  to  customize  the
              configuration for a given system assembly, the format is the one
              described in the mono-config(5) page.

       ~/.config/.mono/keypairs, /usr/share/.mono/keypairs
              Contains  Mono  cryptographic keypairs for users / machine. They
              can  be  accessed  by  using   a   CspParameters   object   with
              DSACryptoServiceProvider and RSACryptoServiceProvider classes.

       ~/.config/.isolatedstorage,            ~/.local/share/.isolatedstorage,
       /usr/share/.isolatedstorage
              Contains  Mono  isolated  storage for non-roaming users, roaming
              users and local machine. Isolated storage can be accessed  using
              the classes from the System.IO.IsolatedStorage namespace.

       <assembly>.config
              Configuration information for individual assemblies is loaded by
              the runtime from side-by-side files with the .config files,  see
              the http://www.mono-project.com/Config for more information.

       Web.config, web.config
              ASP.NET  applications  are  configured  through these files, the
              configuration is  done  on  a  per-directory  basis.   For  more
              information   on   this   subject   see   the   http://www.mono-
              project.com/Config_system.web page.

MAILING LISTS

       Mailing    lists     are     listed     at     the     http://www.mono-
       project.com/Mailing_Lists

WEB SITE

       http://www.mono-project.com

SEE ALSO

       certmgr(1),  csharp(1),  mcs(1),  mdb(1), monocov(1), monodis(1), mono-
       config(5), mozroots(1), pdb2mdb(1), xsp(1), mod_mono(8).

       For more information on AOT: http://www.mono-project.com/AOT

       For ASP.NET-related documentation, see the xsp(1) manual page

                                                                Mono(Mono 2.5)