Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Mono(Mono 4.7.0)					      Mono(Mono	4.7.0)

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

       mono [options] file [arguments...]

       mono-sgen [options] file	[arguments...]

       mono is a runtime implementation	of the	ECMA  Common  Language	Infra-
       structure.  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 dynami-
       cally 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 argu-
       ments 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 ap-
       plications, for developing and debugging, and for testing and debugging
       the runtime itself.

       The  mono  command  uses	the Boehm conservative garbage collector while
       the mono-sgen command uses a moving and generational garbage collector.

       On Unix-based systems, Mono provides a mechanism	to  emulate  the  Win-
       dows-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.

       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 inde-
	      pendent code.  Pre compilation is	just  a	 mechanism  to	reduce
	      startup  time,  increase	code sharing across multiple mono pro-
	      cesses 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 de-
	      tected at	runtime) so you	should not try to move the  pre-gener-
	      ated  assemblies or package the pre-generated assemblies for de-
	      ployment.	 A few options are available as	 a  parameter  to  the
	      --aot  command  line option.   The options are separated by com-
	      mas, and more than one can be specified:

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

		     Instructs the AOT compiler	to output  assembly  code  in-
		     stead of an object	file.

		     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  precom-
		     piled with	AOT.

		     This  instructs  the AOT code generator to	output certain
		     data constructs into a separate file.   This  can	reduce
		     the  executable images some five to twenty	percent.   De-
		     velopers need to then ship	the resulting aotdata as a re-
		     source  and register a hook to load the data on demand by
		     using the mono_install_load_aot_data_hook method.

		     When this option is specified, P/Invoke methods  are  in-
		     voked  directly  instead  of  going through the operating
		     system symbol lookup operation.

		     Same for the llvm tools 'opt' and 'llc'.

		     Instructs the AOT compiler	to generate  offline  sequence
		     points  .msym  files.   The generated .msym files will be
		     stored into a subfolder of	<PATH> named as	 the  compila-
		     tion AOTID.

		     Use  the  GNU  style  target triple <TRIPLE> to determine
		     some      code	  generation	   options,	  i.e.
		     --mtriple=armv7-linux-gnueabi  will  generate  code  that
		     targets ARMv7. This is currently only  supported  by  the
		     ARM  backend.  In	LLVM mode, this	triple is passed on to
		     the LLVM llc compiler.

		     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.

		     Instructs the AOT compiler	to not	output	any  debugging

		     This  prevents  the AOT compiler from generating a	direct
		     calls to a	method.	  The AOT compiler  usually  generates
		     direct  calls for certain methods that do not require go-
		     ing through the PLT (for example, methods that are	 known
		     to	 not require a hook like a static constructor) or call
		     into simple internal calls.

		     Instructs the AOT compiler	to emit	DWARF debugging	infor-
		     mation.  When used	together with the nodebug option, only
		     DWARF debugging information is emitted, but not  the  in-
		     formation that can	be used	at runtime.

		     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.

		     When compiling in full aot	mode, the  method  trampolines
		     must  be  precreated in the AOT image.  You can add addi-
		     tional method trampolines with this  argument.   Defaults
		     to	1024.

		     Instructs	the  AOT  compiler  to	save the output	to the
		     specified file.

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

		     Override the value	of a static readonly  field.  Usually,
		     during JIT	compilation, the static	constructor is ran ea-
		     gerly, so the value of a static readonly field  is	 known
		     at	 compilation  time and the compiler can	do a number of
		     optimizations based  on  it.  During  AOT,	 instead,  the
		     static  constructor  can't	 be ran, so this option	can be
		     used to set the value of such a field and enable the same
		     set  of optimizations.  Type can be any of	i1, i2,	i4 for
		     integers of the respective	sizes (in bytes).   Note  that
		     signed/unsigned  numbers  do  not	matter	here, just the
		     storage size.  This  option  can  be  specified  multiple
		     times  and	 it doesn't prevent the	static constructor for
		     the type defining the field to  execute  with  the	 usual
		     rules  at	runtime	 (hence	possibly computing a different
		     value for the field).

		     Instructs the AOT compiler	to keep	temporary files.

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

	      static Create an ELF object file (.o) or .s file	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);

	      stats  Print various stats collected during AOT compilation.

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

		     Prepends  <PREFIX>	 to  the  name of tools	ran by the AOT
		     compiler, i.e. 'as'/'ld'. For example, --tool=prefix=arm-
		     linux-gnueabi- will make the AOT compiler run

		     Instructs	the AOT	compiler to emit debug symbol informa-

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

	      Currently	 the  only option supported by this command line argu-
	      ment is disable which disables the attach	functionality.

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

	      This instructs the Mono runtime to start a debugging  agent  in-
	      side  the	Mono runtime and connect it to a client	user interface
	      will control the Mono process.  This option is typically used by
	      IDEs, like the MonoDevelop IDE.

       The  configuration  is specified	using one of more of the following op-

		     Use this option to	specify	the IP address where your  de-
		     bugger client is listening	to.

		     Specifies the diagnostics log level for

		     Used to specify the file where the	log will be stored, it
		     defaults to standard output.

		     Defaults to no, with the default  option  Mono  will  ac-
		     tively  connect  to the host/port configured with the ad-
		     dress option.  If you set it to  'y',  it	instructs  the
		     Mono  runtime  to	start  debugging in server mode, where
		     Mono actively waits for the debugger front	end to connect
		     to	 the  Mono process.  Mono will print out to stdout the
		     IP	address	and port where it is listening.

		     If	set to yes, Mono will call setpgid(0, 0)  on  startup,
		     if	that function is available on the system. This is use-
		     ful for ensuring that signals delivered to	a process that
		     is	 executing  the	debuggee are not propagated to the de-
		     buggee, e.g. when Ctrl-C sends SIGINT to the sdb tool.

		     Defaults to yes, with the default option Mono  will  sus-
		     pend  the vm on startup until it connects successfully to
		     a debugger	front end.  If you set it to 'n', in  conjunc-
		     tion  with	server=y, it instructs the Mono	runtime	to run
		     as	normal,	while caching metadata to send to the debugger
		     front end on connection..

		     This  is  used to specify the transport that the debugger
		     will use to communicate.	It must	be specified and  cur-
		     rently requires this to be	'dt_socket'.

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

	      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  up-
	      front and	make sure that you do not use any dynamic features.

       --gc=boehm, --gc=sgen
	      Selects  the  Garbage Collector engine for Mono to use, Boehm or
	      SGen.  Currently this merely ensures that	you are	running	either
	      the  mono	 or mono-sgen commands.	   This	flag can be set	in the
	      MONO_ENV_OPTIONS environment variable to force all of your child
	      processes	 to  use  one particular kind of GC with the Mono run-

       --arch=32, --arch=64
	      (Mac OS X	only): Selects the bitness of the Mono binary used, if
	      available.  If  the binary used is already for the selected bit-
	      ness, nothing changes. If	not, the execution switches to	a  bi-
	      nary  with  the  selected	 bitness suffix	installed side by side
	      (for example, '/bin/mono --arch=64' will switch to '/bin/mono64'
	      iff '/bin/mono' is a 32-bit build).

       --help, -h
	      Displays usage instructions.

       --llvm If  the  Mono  runtime  has been compiled	with LLVM support (not
	      available	in all configurations),	Mono will use the  LLVM	 opti-
	      mization	and code generation engine to JIT or AOT compile.  For
	      more information,	consult:

	      When  using  a Mono that has been	compiled with LLVM support, it
	      forces Mono to fallback to its JIT engine	and not	use  the  LLVM

       --optimize=MODE,	-O=MODE
	      MODE  is a comma separated list of optimizations.	 They also al-
	      low 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 deploy-
	      ment setting, you	might want to actually measure the benefits of
	      using them.  The following optimization flags are	implemented in
	      the core engine:
			   abcrem     Array bound checks removal
			   all	      Turn on all optimizations
			   aot	      Usage of Ahead Of	Time compiled code
			   branch     Branch optimizations
			   cfold      Constant folding
			   cmov	      Conditional moves	[arch-dependency]
			   deadce     Dead code	elimination
			   consprop   Constant propagation
			   copyprop   Copy propagation
			   fcmov      Fast x86 FP compares [arch-dependency]
			   float32     Perform 32-bit float arithmetic using 32-bit operations
			   gshared    Enable generic code sharing.
			   inline     Inline method calls
			   intrins    Intrinsic	method implementations
			   linears    Linear scan global reg allocation
			   leaf	      Leaf procedures optimizations
			   loop	      Loop related optimizations
			   peephole   Peephole postpass
			   precomp    Precompile all methods before executing Main
			   sched      Instruction scheduling
			   shared     Emit per-domain code
			   sse2	      SSE2 instructions	on x86 [arch-dependency]
			   tailc      Tail recursion and tail calls
	      For example, to enable all the optimization but dead code	elimi-
	      nation and inlining, you can use:
	      The flags	that are flagged with [arch-dependency]	indicate  that
	      the  given option	if used	in combination with Ahead of Time com-
	      pilation (--aot flag) would produce pre-compiled code that  will
	      depend  on  the current CPU and might not	be safely moved	to an-
	      other computer.

	      The following optimizations are supported

		     Requests that the runtime performn	32-bit floating	 point
		     operations	using only 32-bits.   By default the Mono run-
		     time tries	to use the  highest  precision	available  for
		     floating  point  operations,  but while this might	render
		     better results, the code might run	slower.	  This options
		     also affects the code generated by	the LLVM backend.

	      inline Controls  whether	the  runtime  should attempt to	inline
		     (the default), or not inline methods invocations

	      Mono supports different runtime versions.	The version  used  de-
	      pends  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 ver-
	      sion 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:

		     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-   for  more  details  and
		     links to the descriptions of this new system.

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

		     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 run-

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

	      Configures  the  virtual	machine	to be better suited for	server
	      operations (currently, allows a heavier  threadpool  initializa-

	      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).

       The following options are used to help when developing a	JITed applica-

       --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  de-
	      bugging  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	InvalidCastEx-
		     ception.	This option needs to be	enabled	as this	gener-
		     ates more verbose code at execution time.

		     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

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

	      Turns on profiling.  For more information	about profiling	appli-
	      cations and code coverage	see the	sections "PROFILING" and "CODE
	      COVERAGE"	below.

       This option can be used multiple	times, each time will load an
	      additional  profiler.    This  allows  developers	to use modules
	      that extend the JIT through the Mono profiling interface.

	      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	 `pro-
	      gram',  `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 run-
	      time.  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

	      Exceptions can also be traced, it	will cause a stack trace to be
	      printed every time an exception of the specified type is thrown.
	      The  exception  type  can	be specified with or without the name-
	      space, and to trace all exceptions, specify 'all'	 as  the  type

		   mono	--trace=E:System.Exception 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 Sys-
	      tem.String except	for the	System.String:Concat method.

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

	      You can trace managed to unmanaged transitions using the wrapper

		   mono	--trace=wrapper	app.exe

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

		   mono	--trace=N:System.Xml

	      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  intruc-
	      tion  per	call, but might	result in significantly	lower floating
	      point and	SIMD performance.

	      Generate a JIT method map	in a /tmp/ file. This file
	      is  then	used, for example, by the perf tool included in	recent
	      Linux kernels.  Each line	in the file has:

		   HEXADDR HEXSIZE methodname

	      Currently	this option is only supported on Linux.

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

	      This  flag  is  used by the automatic optimization bug bisector.
	      It takes an optimization flag and	a filename of a	file  contain-
	      ing a list of full method	names, one per line.  When it compiles
	      one of the methods in the	file  it  will	use  the  optimization
	      given,  in  addition to the optimizations	that are otherwise en-
	      abled.  Note that	if the optimization is enabled by default, you
	      should disable it	with `-O`, otherwise it	will just apply	to ev-
	      ery method, whether it's in the file or not.

       --break method
	      Inserts a	breakpoint before the method whose  name  is  `method'
	      (namespace.class:methodname).   Use `Main' as method name	to in-
	      sert a breakpoint	on the application's main method.  You can use
	      it    also    with   generics,   for   example   "System.Collec-

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

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

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

       --graph=TYPE METHOD
	      This generates a postscript file with a graph with  the  details
	      about  the  specified  method (  This
	      requires `dot' and ghostview to be installed (it expects	Ghost-
	      view 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.

	      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 genera-
	      tor performance.

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

	      Perform maintenance of the process  shared  data.	  semdel  will
	      delete  the  global semaphore.  hps will list the	currently used

       -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	selec-
	      tor info etc.).

       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

       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.

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


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

       If a profiler is	not specified, the default profiler is used.  The pro-
       filer_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 op-
       tions 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 exam-

	    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 pro-
       gram.exe. The profile data is put in prof.out.  Note that the statisti-
       cal  profiler  has a very low overhead and should be the	preferred pro-
       filer 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).

       This is the most	advanced profiler.

       The Mono	log profiler can be used to collect a lot of information about
       a  program  running  in	the Mono runtime.  This	data can be used (both
       while the process is running and	later) to do analyses of  the  program
       behaviour,  determine  resource	usage, performance issues or even look
       for particular execution	patterns.

       This is accomplished by logging the events provided by the Mono runtime
       through the profiling interface and periodically	writing	them to	a file
       which can be later inspected with the mprof-report(1) tool.

       More information	about how to use the log profiler is available on  the
       mprof-report(1) page.

       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 `'.  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

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

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

       Mono  ships  with  a code coverage module.  This	module is activated by
       using the Mono --profile=cov option.  The format	is: --profile=cov[:as-
       sembly-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 fol-
       lowing command line limits the code coverage to routines	in the	"demo"

	    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 name-

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

       Which will only perform code coverage in	the given assembly  and	 name-

       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.

       You can improve startup performance by using the	AOT profiler.

       Typically the AOT compiler (mono	--aot)	will  not  generate  code  for
       generic	instantiations.	  To solve this, you can run Mono with the AOT
       profiler	to find	out all	the generic instantiations that	are used,  and
       then instructing	the AOT	compiler to produce code for these.

       This command will run the specified app.exe and produce the out.aotprof
       file with the data  describing  the  generic  instantiations  that  are
	    $ mono --profile=aot:output=out.aotprof app.exe

       Once  you  have	this data, you can pass	this to	Mono's AOT compiler to
       instruct	it to generate code for	it:
	    $ mono --aot=profile=out.aotprof

       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  com-
       mand 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

       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 guaran-
       teed and	the application	might crash or terminate at  any  given	 point

       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 li-
       brary loader), "gc" (garbage collector),	"cfg"  (config	file  loader),
       "aot"  (precompiler),  "security"  (e.g.	 Moonlight  CoreCLR  support),
       "threadpool" (thread pool generic), "io-threadpool" (thread pool	 I/O),
       "io-layer" (I/O layer - sockets,	handles, shared	memory etc) and	"all".
       The default value is "all". Changing the	mask value allows you to  dis-
       play  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

       If you are using	LLDB, you can use the script to	print some in-
       ternal data structures with  it.	   To  use  this,  add	this  to  your
       $HOME/.lldbinit file:
       command script import $PREFIX/lib/mono/lldb/

       Where  $PREFIX  is  the	prefix value that you used when	you configured
       Mono (typically /usr).

       Once this is done, then you can inspect some Mono Runtime  data	struc-
       tures, for example:
       (lldb) p	method

       (MonoMethod *) $0 = 0x05026ac0 [mscorlib]System.OutOfMemoryException:.ctor()

       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 vari-

       The possible values are `no' to disable the use of a C# customized  se-
       rializer,  or  an integer that is the minimum number of uses before the
       runtime will produce a custom serializer	(0 will	produce	a custom seri-
       alizer  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).

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

	      (Also  http_proxy) If set, web requests using the	Mono Class Li-
	      brary will be automatically proxied through the given URL.   Not
	      supported	on Windows, Mac	OS, iOS	or Android. See	also NO_PROXY.

	      When Mono	is compiled with LLVM support, this instructs the run-
	      time 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.

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

	      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 $pre-
	      fix/etc/mono/2.0/ file and, optionally, in the  set-	 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 has a cache of ConfigSection	objects	for speeding  up  Web-
	      ConfigurationManager queries. Its	default	size is	100 items, and
	      when more	items are needed, cache	evictions start	happening.  If
	      evictions	 are  too frequent this	could impose unnecessary over-
	      head, which could	be avoided by using this environment  variable
	      to  set  up a higher cache size (or to lower memory requirements
	      by decreasing it).

	      If set, causes Mono.Cairo	to collect stack traces	 when  objects
	      are allocated, so	that the finalization/Dispose warnings include
	      information about	the instance's origin.

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

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

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

	      Override	the  automatic cpu detection mechanism.	Currently used
	      only on arm.  The	format of the value is as follows:

		   "armvV [thumb[2]]"

	      where V is the architecture number 4, 5, 6, 7  and  the  options
	      can be currently be "thumb" or "thumb2". Example:

		   MONO_CPU_ARCH="armv4	thumb" mono ...

	      When  Mono  is  built with a soft	float fallback on ARM and this
	      variable is set to "1", Mono will	always emit soft  float	 code,
	      even if a	VFP unit is detected.

	      This  is	a  debugging  aid used to force	limits on the FileSys-
	      temWatcher implementation	in Darwin.   There is no limit by  de-

	      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.

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

	      Unix  only:  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.  This is the default from mono	2.8 onwards.

	      Unix  only:  If set, disable usage of shared memory for exposing
	      performance counters. This means it will not be possible to both
	      externally read performance counters from	this processes or read
	      those of external	processes.

	      When set,	enables	the use	of a fully managed  DNS	 resolver  in-
	      stead of the regular libc	functions. This	resolver performs much
	      better when multiple queries are run in parallel.

	      Note that	/etc/nsswitch.conf will	be ignored.

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

	      This makes the Mono runtime and the SGen garbage	collector  run
	      in cooperative mode as opposed to	run on preemptive mode.	  Pre-
	      emptive mode is the mode that Mono has used historically,	 going
	      back to the Boehm	days, where the	garbage	collector would	run at
	      any point	and suspend execution of all threads  as  required  to
	      perform a	garbage	collection.  The cooperative mode on the other
	      hand requires the	cooperation of all threads to stop at  a  safe
	      point.	This  makes  for an easier to debug garbage collector.
	      As of Mono 4.3.0 it is a work in progress, and while  it	works,
	      it has not been used extensively.	  This option enabled the fea-
	      ture and allows us to find spots that need to be tuned for  this
	      mode  of operation.   Alternatively, this	mode can be enabled at
	      compile time by using the	--with-cooperative-gc flag when	 call-
	      ing configure.

	      This  environment	variable allows	you to pass command line argu-
	      ments to a Mono process through the environment.	 This is  use-
	      ful  for example to force	all of your Mono processes to use LLVM
	      or SGEN without having to	modify any launch scripts.

	      Used to pass extra options to the	debugger agent in the runtime,
	      as they were passed using	--debugger-agent=.

	      Sets  the	type of	event log provider to use (for System.Diagnos-
	      tics.EventLog).  Possible	values are:

		     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\vent-
		     log" 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 per-
		     mission for individual event log and event	source	direc-
		     tories  is	 set to	777 (with +t bit) allowing everyone to
		     read and write event log entries while only allowing  en-
		     tries 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).

	      If set, contains a colon-separated list of text encodings	to try
	      when  turning externally-generated text (e.g. command-line argu-
	      ments or filenames) into Unicode.	 The encoding names come  from
	      the  list	 provided  by iconv, and the special case "default_lo-
	      cale" 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 suc-
	      cessful 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.

	      When  using  Mono	 with the SGen garbage collector this variable
	      controls several parameters of the  collector.   The  variable's
	      value is a comma separated list of words.

		     Sets  the maximum size of the heap. The size is specified
		     in	bytes and must be a power of two.  The	suffixes  `k',
		     `m' and `g' can be	used to	specify	kilo-, mega- and giga-
		     bytes, respectively. The limit is the sum of the nursery,
		     major  heap  and  large  object  heap.  Once the limit is
		     reached the application  will  receive  OutOfMemoryExcep-
		     tions  when  trying  to allocate.	Not the	full extent of
		     memory set	in max-heap-size could be available to satisfy
		     a single allocation due to	internal fragmentation.	By de-
		     fault heap	limits is disabled and the GC will try to  use
		     all available memory.

		     Sets  the	size of	the nursery.  The size is specified in
		     bytes and must be a power of two.	The suffixes `k',  `m'
		     and  `g'  can  be	used to	specify	kilo-, mega- and giga-
		     bytes, respectively.  The nursery is the first generation
		     (of  two).	  A  larger  nursery will usually speed	up the
		     program but will obviously	use more memory.  The  default
		     nursery size 4 MB.

	      major=collector Specifies	which major collector to use.
		     Options are `marksweep' for the Mark&Sweep	collector, and
		     `marksweep-conc' for concurrent Mark&Sweep.  The non-con-
		     current Mark&Sweep	collector is the default.

		     Once  the	heap  size  gets larger	than this size,	ignore
		     what the default major collection trigger metric says and
		     only  allow  four nursery size's of major heap growth be-
		     tween major collections.

		     Sets the evacuation threshold in percent.	This option is
		     only  available  on the Mark&Sweep	major collectors.  The
		     value must	be an integer in the range 0 to	100.  The  de-
		     fault  is 66.  If the sweep phase of the collection finds
		     that the occupancy	of a specific heap block type is  less
		     than this percentage, it will do a	copying	collection for
		     that block	type in	the  next  major  collection,  thereby
		     restoring	occupancy to close to 100 percent.  A value of
		     0 turns evacuation	off.

		     Enables or	disables lazy sweep for	the Mark&Sweep collec-
		     tor.   If	enabled, the sweeping of individual major heap
		     blocks is done piecemeal whenever the need	arises,	 typi-
		     cally  during  nursery collections.  Lazy sweeping	is en-
		     abled by default.

		     Enables or	disables concurrent sweep for  the  Mark&Sweep
		     collector.	 If enabled, the iteration of all major	blocks
		     to	determine which	ones can be freed and which ones  have
		     to	 be kept and swept, is done concurrently with the run-
		     ning program.  Concurrent sweeping	is enabled by default.

		     Specifies how application threads should be scanned.  Op-
		     tions  are	 `precise` and `conservative`. Precise marking
		     allow the collector to know what values on	stack are ref-
		     erences  and  what	are not.  Conservative marking threats
		     all values	as potentially references and leave  them  un-
		     touched. Precise marking reduces floating garbage and can
		     speed up nursery collection and allocation	rate,  it  has
		     the  downside of requiring	a significant extra memory per
		     compiled method. The  right  option,  unfortunately,  re-
		     quires experimentation.

		     Specifies	the target save	ratio for the major collector.
		     The collector lets	a given	amount of memory  to  be  pro-
		     moted from	the nursery due	to minor collections before it
		     triggers a	major collection. This amount is based on  how
		     much  memory  it  expects to free.	It is represented as a
		     ratio of the size of the heap after a  major  collection.
		     Valid values are between 0.1 and 2.0. The default is 0.5.
		     Smaller values will keep the major	heap size smaller  but
		     will  trigger  more  major	 collections. Likewise,	bigger
		     values will use more memory and result in	less  frequent
		     major  collections.   This	 option	is EXPERIMENTAL, so it
		     might disappear in	later versions of mono.

		     Specifies the default allocation allowance	when the  cal-
		     culated  size  is	too small. The allocation allowance is
		     how much memory the  collector  let  be  promoted	before
		     triggered a major collection.  It is a ratio of the nurs-
		     ery size.	Valid values are between 1.0 and 10.0. The de-
		     fault  is	4.0.  Smaller values lead to smaller heaps and
		     more frequent major collections.  Likewise, bigger	values
		     will  allow  the  heap to grow faster but use more	memory
		     when it reaches a stable size.  This option is EXPERIMEN-
		     TAL, so it	might disappear	in later versions of mono.

		     Specifies which minor collector to	use. Options are 'sim-
		     ple' which	promotes all objects from the nursery directly
		     to	 the old generation and	'split'	which lets object stay
		     longer on the nursery before promoting.

		     Specifies the ratio of memory from	the nursery to be  use
		     by	 the alloc space.  This	only can only be used with the
		     split minor collector.  Valid values are integers between
		     1 and 100.	Default	is 60.

		     Specifies the required age	of an object must reach	inside
		     the nursery before	been promoted to the  old  generation.
		     This  only	 can only be used with the split minor collec-
		     tor.  Valid values	are integers between 1 and 14. Default
		     is	2.

		     Enables  or  disables  cementing.	 This can dramatically
		     shorten nursery collection	times on some benchmarks where
		     pinned objects are	referred to from the major heap.

		     This forbids the major collector from performing synchro-
		     nous major	collections.  The major	collector  might  want
		     to	 do a synchronous collection due to excessive fragmen-
		     tation. Disabling this might trigger OutOfMemory error in
		     situations	that would otherwise not happen.

	      When using Mono with the SGen garbage collector this environment
	      variable can be used to turn on various  debugging  features  of
	      the  collector.  The value of this variable is a comma separated
	      list of words.  Do not use these options in production.

	      number Sets the debug level to the specified number.

		     After each	major collection prints	memory consumption for
		     before and	after the collection and the allowance for the
		     minor collector, i.e. how much the	 heap  is  allowed  to
		     grow from minor collections before	the next major collec-
		     tion is triggered.

		     Gathers statistics	 on  the  classes  whose  objects  are
		     pinned in the nursery and for which global	remset entries
		     are added.	 Prints	those statistics when shutting down.


		     This performs a remset consistency	check at  various  op-
		     portunities,  and	also  clears the nursery at collection
		     time, instead of the default, when	buffers	are  allocated
		     (clear-at-gc).   The consistency check ensures that there
		     are no major to minor references that are not on the  re-
		     membered sets.

		     Checks  that the mod-union	cardtable is consistent	before
		     each finishing major collection  pause.   This  check  is
		     only applicable to	concurrent major collectors.

		     Checks that mark bits in the major	heap are consistent at
		     the end of	each major collection.	Consistent  mark  bits
		     mean that if an object is marked, all objects that	it had
		     references	to must	also be	marked.

		     After nursery collections,	and before starting concurrent
		     collections,   check  whether  all	 nursery  objects  are
		     pinned, or	not pinned - depending on context.  Does noth-
		     ing when the split	nursery	collector is used.

		     Performs a	check to make sure that	no references are left
		     to	an unloaded AppDomain.

		     Clears the	nursery	incrementally when  the	 thread	 local
		     allocation	 buffers (TLAB)	are created.  The default set-
		     ting clears the whole nursery at GC time.

		     Clears the	nursery	incrementally when  the	 thread	 local
		     allocation	 buffers  (TLAB)  are  created,	but at GC time
		     fills it with the byte `0xff`, which should result	 in  a
		     crash  more  quickly  if `clear-at-tlab-creation` doesn't
		     work properly.

		     This clears the nursery at	GC time	instead	 of  doing  it
		     when  the	thread	local allocation buffer	(TLAB) is cre-
		     ated.  The	default	is to clear the	nursery	at  TLAB  cre-
		     ation time.

		     Don't  do	minor  collections.  If	the nursery is full, a
		     major collection is triggered instead, unless it, too, is

		     Don't do major collections.

		     Forces  the  GC to	scan the stack conservatively, even if
		     precise scanning is available.

		     Disables the managed allocator.

		     If	set, does a plausibility check on the scan_starts  be-
		     fore and after each collection

		     If	set, does a complete object walk of the	nursery	at the
		     start of each minor collection.

		     If	set, dumps the contents	of the nursery at the start of
		     each  minor collection. Requires verify-nursery-at-minor-
		     gc	to be set.

		     Dumps the heap contents to	the specified file.   To visu-
		     alize the information, use	the mono-heapviz tool.

		     Outputs the debugging output to the specified file.   For
		     this to work, Mono	needs to  be  compiled	with  the  BI-
		     NARY_PROTOCOL  define  on	sgen-gc.c.    You can then use
		     this command to explore the output
				     sgen-grep-binprot 0x1234 0x5678 < file

		     If	set, objects allocated in  the	nursery	 are  suffixed
		     with  a canary (guard) word, which	is checked on each mi-
		     nor collection. Can be used to detect/debug heap  corrup-
		     tion issues.

		     If	 enabled, finalizers will not be run.  Everything else
		     will be unaffected: finalizable objects will still	be put
		     into  the	finalization  queue  where  they survive until
		     they're scheduled to finalize.  Once they're not  in  the
		     queue  anymore  they  will	 be collected regularly.  If a
		     list of comma-separated class names is  given,  only  ob-
		     jects from	those classes will not be finalized.

		     Log  verbosely around the finalization process to aid de-

	      Provides a prefix	the runtime uses to look for  Global  Assembly
	      Caches.	Directories are	separated by the platform path separa-
	      tor (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/user-

	      Enables  some filename rewriting support to assist badly-written
	      applications that	hard-code Windows paths.  Set to a colon-sepa-
	      rated  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:

		   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.

	      Additionally.  Mono  includes a profiler module which allows one
	      to track what adjustements to file paths IOMAP code needs	to do.
	      The  tracking  code  reports  the	 managed  location (full stack
	      trace) from which	the IOMAP-ed call was  made  and,  on  process
	      exit,  the locations where all the IOMAP-ed strings were created
	      in managed code. The latter report is only approximate as	it  is
	      not  always  possible  to	estimate the actual location where the
	      string was created. The code uses	simple heuristics  -  it  ana-
	      lyzes stack trace	leading	back to	the string allocation location
	      and ignores all the managed code which lives in  assemblies  in-
	      stalled  in  GAC	as well	as in the class	libraries shipped with
	      Mono (since they are assumed to be free of case-sensitivity  is-
	      sues).  It  then reports the first location in the user's	code -
	      in most cases this will be the place where the string  is	 allo-
	      cated  or	 very close to the location. The reporting code	is im-
	      plemented	as a custom profiler module (see the "PROFILING"  sec-
	      tion) and	can be loaded in the following way:

		   mono	--profile=iomap	yourapplication.exe

	      Note,  however,  that  Mono currently supports only one profiler
	      module at	a time.

	      When Mono	is using the LLVM code generation backend you can  use
	      this environment variable	to pass	code generation	options	to the
	      LLVM compiler.

	      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,	  Sys-
	      tem.IO.FileSystemWatcher	will use the default managed implemen-
	      tation (slow). If	unset, mono will  try  to  use	inotify,  FAM,
	      Gamin,  kevent  under  Unix systems and native API calls on Win-
	      dows, falling back to the	managed	implementation on error.

	      Mono supports a plugin model  for	 its  implementation  of  Sys-
	      tem.Messaging making it possible to support a variety of messag-
	      ing 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:


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

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

	      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:
	      Relative paths are resolved based	on the launch-time current directory.
	      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

	      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.

	      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.

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

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

	      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.

	      The minimum number of threads in the general threadpool will be
	      MONO_THREADS_PER_CPU * number of CPUs. The default value for this
	      variable is 1.

	      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.

	      Sets the revocation mode used when validating a X509 certificate chain (https,
	      ftps, smtps...).	The default is 'nocheck', which	performs no revocation check
	      at all. The other	possible values	are 'offline', which performs CRL check	(not
	      implemented yet) and 'online' which uses OCSP and	CRL to verify the revocation
	      status (not implemented yet).

	      (Also no_proxy) If both HTTP_PROXY and NO_PROXY are
	      set, NO_PROXY will be treated as a comma-separated list of "bypass" domains
	      which will not be	sent through the proxy.	Domains	in NO_PROXY may	contain
	      wildcards, as in "*" or "build????.local". Not supported	on
	      Windows, Mac OS, iOS or Android.

	      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.

	      If set, enables some features of the runtime useful  for	debug-
	      ging.   This  variable  should contain a comma separated list of
	      debugging	options.  Currently, the following  options  are  sup-

		     Enables small structs alignment to	4/8 bytes.

		     When  this	 option	 is set	on ARM,	a fallback TLS will be
		     used instead of the default fast TLS.

		     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	debug-
		     ging verifier problems

	      casts  This  option can be used to get more detailed information
		     from InvalidCast exceptions, it will provide  information
		     about the types involved.

		     This  option causes the runtime to	check for calling con-
		     vention  mismatches  when	using  pinvoke,	 i.e.	mixing
		     cdecl/stdcall. It only works on windows. If a mismatch is
		     detected, an ExecutionEngineException is thrown.

		     Collects information about	pagefaults.   This is used in-
		     ternally  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.

		     When  this	option is set, the runtime will	invalidate the
		     domain memory pool	instead	of destroying it.

		     Disables a	compiler optimization where the	frame  pointer
		     is	omitted	from the stack.	This optimization can interact
		     badly with	debuggers.

		     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  al-
		     locations	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).

		     Instructs the runtime to try to use a generic runtime-in-
		     voke wrapper instead of creating one invoke wrapper.

		     Makes the JIT generate an explicit	NULL check on variable
		     dereferences instead of depending on the operating	system
		     to	 raise a SIGSEGV or another form of trap event when an
		     invalid memory location is	accessed.

	      gdb    Equivalent	to  setting  the  MONO_XDEBUG  variable,  this
		     emits  symbols into a shared library as the code is JITed
		     that can be loaded	into GDB to inspect symbols.

		     Automatically generates  sequence	points	where  the  IL
		     stack  is empty.  These are places	where the debugger can
		     set a breakpoint.

		     Unless the	option is used,	the runtime generates sequence
		     points  data  that	maps native offsets to IL offsets. Se-
		     quence point data is used to display IL offset in	stack-
		     traces.  Stacktraces  with	IL offsets can be symbolicated
		     using mono-symbolicate tool.

		     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  dis-
		     plays the stack trace of a	single thread.

		     Instructs	the  runtime to	initialize the stack with some
		     known values (0x2a	on x86-64) at the start	of a method to
		     assist in debuggin	the JIT	engine.

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

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

		     When this option is set, the runtime can share  generated
		     code  between  generic  types  effectively	 reducing  the
		     amount of code generated.

		     This option will cause mono to abort with	a  descriptive
		     message when during stack unwinding after an exception it
		     reaches a native stack frame. This	happens	when a managed
		     delegate  is passed to native code, and the managed dele-
		     gate throws an exception. Mono will normally try  to  un-
		     wind  the stack to	the first (managed) exception handler,
		     and it will skip any native stack frames in the  process.
		     This  leads  to  undefined	 behaviour (since mono doesn't
		     know how to process native	frames), leaks,	 and  possibly
		     crashes too.

		     This  guarantees  that each time managed code is compiled
		     the same instructions and registers are used,  regardless
		     of	the size of used values.

		     This  option allows using single-steps and	breakpoints in
		     hardware where we cannot do it with signals.

		     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.

		     This  option  will	 suspend the program when an exception

		     This option will suspend the program  when	 an  unhandled
		     exception occurs.

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

	      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 li-
	      brary loader), "gc"  (garbage  collector),  "cfg"	 (config  file
	      loader), "aot" (precompiler), "security" (e.g. Moonlight CoreCLR
	      support) 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 mes-
	      sages set	you mask to "asm,cfg".

	      Controls where trace log messages	are written. If	not  set  then
	      the  messages go to stdout.  If set, the string either specifies
	      a	path to	a file that will have messages appended	to it, or  the
	      string  "syslog"	in  which case the messages will be written to
	      the system log.  Under Windows, this is simulated	by writing  to
	      a	 file  called  "mono.log".   MONO_LOG_HEADER  Controls whether
	      trace log	messages not directed to syslog	 have  the  id,	 time-
	      stamp,  and  pid	as  the	prefix to the log message. To enable a
	      header this environment variable need just be non-null.

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

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

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

	      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 stan-
	      dard error, respectively.	If it's	set  to	 Console.Out  or  Con-
	      sole.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.

	      This eases WCF diagnostics functionality by simply  outputs  all
	      log  messages  from WCF engine to	"stdout", "stderr" or any file
	      passed to	this environment variable. The log format is the  same
	      as usual diagnostic output.

	      This throws an exception when a X11 error	is encountered;	by de-
	      fault a message is displayed but execution continues

	      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.

	      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  cer-
	      tain problems.

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

	      Enables the maximum JIT verbosity	for the	specified method. This
	      is very helpfull to diagnose a miscompilation problems of	a spe-
	      cific method.

	      Enables sending of the JITs intermediate	representation	for  a
	      specified	method to the IdealGraphVisualizer tool.

	      If set, makes the	JIT output information about detected CPU fea-
	      tures (such as SSE, CMOV,	FCMOV, etc) to stdout.

	      If set, the JIT will not perform any hardware capability	detec-
	      tion.  This  may	be useful to pinpoint the cause	of JIT issues.
	      This is the default when Mono is built as	an AOT cross compiler,
	      so that the generated code will run on most hardware.

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

       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

       Mono's Ping implementation for detecting	network	reachability can  cre-
       ate  the	 ICMP packets itself without requiring the system ping command
       to do the work.	If you want to	enable	this  on  Linux	 for  non-root
       users, you need to give the Mono	binary special permissions.

       As root,	run this command:
	  # setcap cap_net_raw=+ep /usr/bin/mono

       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.

	      The directory for	the ahead-of-time compiler demand creation as-
	      semblies 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 certifi-
	      cate stores and the mozroots(1) page for information on  how  to
	      import  the  Mozilla root	certificates into the Mono certificate

	      Files in this directory allow a user to customize	the configura-
	      tion  for	 a  given  system  assembly, the format	is the one de-
	      scribed 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 DSACryp-
	      toServiceProvider	and RSACryptoServiceProvider classes.

       ~/.config/.isolatedstorage,	      ~/.local/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.

	      Configuration information	for individual assemblies is loaded by
	      the runtime from side-by-side files with the .config files,  see
	      the 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	infor-
	      mation  on this subject see the
	      fig_system.web page.

       Mailing lists  are  listed  at  the


       certmgr(1),  csharp(1),	mcs(1),	 mdb(1), monocov(1), monodis(1), mono-
       config(5),   mozroots(1),    mprof-report(1),	pdb2mdb(1),    xsp(1),

       For   more  information	on  AOT:

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

							      Mono(Mono	4.7.0)


Want to link to this manual page? Use this URL:

home | help