+.SH 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.
+.PP
+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.
+.PP
+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.
+.PP
+This support allows for example debugging applications by having the
+csharp shell attach to running processes.
+.SH 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:
+.nf
+
+ --profile[=profiler[:profiler_args]]
+
+.fi
+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.
+.PP
+If a
+.I profiler
+is not specified, the default profiler is used.
+.Sp
+The
+.I profiler_args
+is a profiler-specific string of options for the profiler itself.
+.Sp
+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'.
+.PP
+By default the
+profile data is printed to stdout: to change this, use the 'file=filename'
+option to output the data to filename.
+.Sp
+For example:
+.nf
+
+ mono --profile program.exe
+
+.fi
+.Sp
+That will run the program with the default profiler and will do time
+and allocation profiling.
+.Sp
+.nf
+
+ mono --profile=default:stat,alloc,file=prof.out program.exe
+
+.fi
+Will do sample statistical profiling and allocation profiling on
+program.exe. The profile data is put in prof.out.
+.Sp
+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).
+.SH LOGGING PROFILER
+.PP
+The
+.I logging profiler
+will eventually replace the default profiler as it is more complete
+and encompasses the functionality of all the other profilers for Mono.
+It supports the following execution modes:
+.IP
+.I Statistical:
+the program instruction pointer is periodically sampled (it works also with
+unmanaged functions). If call chains are requested, for each sample the
+profiler gets a partial stack trace (up to a desired depth) so that
+caller-callee information is available.
+.IP
+.I 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.
+.IP
+.I Allocation:
+each allocation is logged.
+.IP
+.I 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).
+.IP
+.I 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.
+.PP
+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.
+.PP
+Instead of reporting the collected
+information at the end of the execution of the program, this profiler logs
+all the events periodically into a file during program execution.
+To minimize the performance impact with multi-threaded applications,
+the logging uses per-thread buffers that are routinely saved to disk.
+.PP
+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.
+.PP
+This profiler is activated passing the \fB--profile=logging\fR option to
+the mono runtime, and is controlled attaching further options, like
+\fB--profile=logging:statistical\fR for doing statistical profiling (multiple
+options are separated by commas).
+.PP
+As a quick primer, here are a few examples of the most common usage modes:
+.PP
+To write the resulting data to "mydata.mprof" (defaults to statistical
+profiling):
+.nf
+
+ mono --profile=logging:output=mydata.mprof program.exe
+.fi
+.PP
+To perform statistical profiling, inspecting call chains up to depth 8:
+.nf
+
+ mono --profile=logging:statistical=8 program.exe
+.fi
+.PP
+To profile allocations (by default the call stack will be analized for
+each allocation, producing detailed caller method attribution infornation):
+.nf
+
+ mono --profile=logging:allocations program.exe
+.fi
+.PP
+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):
+.nf
+
+ mono --profile=logging:allocations-summary program.exe
+.fi
+.PP
+To perform heap profiling taking heap snapshots:
+.nf
+
+ mono --profile=logging:heap=all program.exe
+ mono --profile=logging:heap=<signal> program.exe
+.fi
+
+If "all" is specified, a heap snapshot is taken at each collection.
+If, instead, a signal name or number is given (one of SIGUSR1, SIGUSR2 and
+SIGPROF, remembering that SIGPROF is not compatible with the statistical
+profiler), a garbage collection is forced and a snapshot is taken every
+time the signal is received.
+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".
+
+.PP
+Then you would need to invoke the decoder \fImprof-decoder(1)\fR
+on the output file to see the profiling results, or to examine heap
+snapshots and allocations in detail \fImprof-heap-viewer(1)\fR.
+
+.PP
+The operating modes described above are the default ones, and are sufficient
+to use the profiler.
+.PP
+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.
+.PP
+These are all the available options, organized by category:
+.PP
+\fBExecution profiling modes\fR
+.RS
+.ne 8