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

FreeBSD Manual Pages


home | help
Mono(mono)							    Mono(mono)

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

       These  executables  can reference additionaly functionality in the form
       of assembly references.	By default those assembly references  are  re-
       solved as follows: the mscorlib.dll is resolved from the	system profile
       that is configured by Mono, and other assemblies	are  loaded  from  the
       Global Assembly Cache (GAC).

       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 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 moving and generational SGen garbage collec-
       tor while the mono-boehm	command	uses the  conservative	Boehm  garbage

       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.   Precompilation  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:

		     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.

		     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,  icalls  (internal	 calls
		     made  from	 the  standard	library	 into the mono runtime
		     code) are invoked directly	instead	of going  through  the
		     operating	system symbol lookup operation.	 This requires
		     use of the	static option.

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

		     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.

	      full   This creates binaries which can be	used with the  --full-
		     aot option.

	      hybrid This  creates  binaries  which can	be used	with the --hy-
		     brid-aot option.

	      llvm   AOT will be performed with	the LLVM  backend  instead  of
		     the  Mono	backend	where possible.	This will be slower to
		     compile but most likely result in a performance  improve-

		     AOT  will	be performed with the LLVM backend exclusively
		     and the Mono backend will not be used. The	only output in
		     this  mode	 will  be  the bitcode file normally specified
		     with the llvm-outfile option. Use of  llvmonly  automati-
		     cally  enables the	full and llvm options. This feature is

		     Gives the path for	the temporary LLVM bitcode  file  cre-
		     ated  during  AOT.	  dedup	Each AOT module	will typically
		     contain the code for inflated methods and	wrappers  that
		     are  called  by  code  in	that module. In	dedup mode, we
		     identify and skip compiling all of	 those	methods.  When
		     using  this  mode with fullaot, dedup-include is required
		     or	these methods will remain missing.

		     In	dedup-include mode, we are in the pass of  compilation
		     where  we	compile	 the  methods  that  we	had previously
		     skipped. All of them are emitted into the	assembly  that
		     is	 passed	as this	option.	We consolidate the many	dupli-
		     cate skipped copies of the	same method into one.

	      info   Print the architecture the	AOT in this copy of Mono  tar-
		     gets and quit.

	      interp Generates	all  required wrappers,	so that	it is possible
		     to	run --interpreter without any code generation at  run-
		     time.   This  option  only	makes sense with mscorlib.dll.
		     Embedders can set

		     mono_jit_set_aot_mode (MONO_AOT_MODE_INTERP);

		     Additional	flags to pass to the C linker (if the  current
		     AOT mode calls for	invoking it).

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

		     When  compiling  in full aot mode,	the value type generic
		     sharing trampolines must be precreated in the AOT	image.
		     You can add additional method trampolines with this argu-
		     ment.  Defaults to	512.

		     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.

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

		     When  compiling  in  full	aot  mode, the generic sharing
		     fetch trampolines must be precreated in  the  AOT	image.
		     You can add additional method trampolines with this argu-
		     ment.  Defaults to	128.

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

		     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.

		     Specify a file to use  for	 profile-guided	 optimization.
		     See  the  AOT  profiler  sub-section. To specify multiple
		     files, include the	profile	option multiple	times.

		     AOT *only*	the methods described in the  files  specified
		     with  the	profile	 option. See the AOT profiler sub-sec-

		     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.

		     Explicitly	specify	path to	store temporary	files  created
		     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

		     Prints additional information about  type	loading	 fail-

		     Instructs	the  AOT  compiler to emit (or not emit) debug
		     symbol information.

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

	      List of additional directories to	search for AOT images.

	      Apply  the  assembly  bindings  from the specified configuration
	      file when	running	the AOT	compiler.  This	is useful when compil-
	      ing  an auxiliary	assembly that is referenced by a main assembly
	      that provides a configuration file.   For	 example,  if  app.exe
	      uses  lib.dll  then  in order to make the	assembly bindings from
	      app.exe.config available when compiling lib.dll ahead  of	 time,
		   mono	--apply-bindings=app.exe.config	--aot lib.dll

	      If  mode	is  strict, Mono will check that the public key	token,
	      culture and version of a	candidate  assembly  matches  the  re-
	      quested  strong  name.   If  mode	is legacy, as long as the name
	      matches, the candidate will be allowed. strict is	 the  behavior
	      consistent with .NET Framework but may break some	existing mono-
	      based applications.  The default is legacy.

	      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 or Visual Studio IDEs.
	      The configuration	is specified using one of more of the  follow-
	      ing options:

			    Use	 this  option  to specify the IP address where
			    your debugger 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
			    actively connect to	the host/port configured  with
			    the	 address option.  If you set it	to 'y',	it in-
			    structs the	Mono runtime  to  start	 debugging  in
			    server mode, where Mono actively waits for the de-
			    bugger 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 sys-
			    tem. This is useful	for ensuring that signals  de-
			    livered  to	 a  process  that is executing the de-
			    buggee are not propagated to  the  debuggee,  e.g.
			    when Ctrl-C	sends SIGINT to	the sdb	tool.

			    Defaults to	yes, with the default option Mono will
			    suspend the	vm on startup until it	connects  suc-
			    cessfully  to a debugger front end.	 If you	set it
			    to 'n', in conjunction with	server=y, it instructs
			    the	 Mono  runtime to run as normal, while caching
			    metadata to	send to	the debugger front end on con-

			    This is used to specify the	transport that the de-
			    bugger will	use to communicate.   It must be spec-
			    ified   and	  currently   requires	 this	to  be

		     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.

		     This  flag	instructs the Mono runtime to not generate any
		     code at runtime and depend	exclusively on the code	gener-
		     ated from using mono --aot=full previously.  This is use-
		     ful for platforms that do not permit dynamic code genera-
		     tion,  or	if  you	 need to run assemblies	that have been
		     stripped of IL (for example using	mono-cil-strip).   No-
		     tice that this feature will abort execution at runtime if
		     a codepath	in your	program, or Mono's class libraries at-
		     tempts  to	 generate  code	 dynamically.  You should test
		     your software upfront 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 runtime.

		     Command line equivalent of	the MONO_GC_DEBUG  environment

		     Command line equivalent of	the MONO_GC_PARAMS environment

	      --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 bitness, nothing changes.	If not,	the  execution
		     switches to a binary with the selected bitness suffix in-
		     stalled side by side (for example,	'/bin/mono  --arch=64'
		     will  switch to '/bin/mono64' iff '/bin/mono' is a	32-bit

	      --help, -h
		     Displays usage instructions.

		     The Mono runtime will use its interpreter	to  execute  a
		     given  assembly.	The interpreter	is usually slower than
		     the JIT, but it can be useful  on	platforms  where  code
		     generation	at runtime is not allowed.

		     This  flag	allows the Mono	runtime	to run assemblies that
		     have been stripped	of IL,	for  example  using  mono-cil-
		     strip.  For this to work, the assembly must have been AOT
		     compiled with --aot=hybrid.

		     This flag is similar to --full-aot, but it	does not  dis-
		     able  the	JIT.  This  means you can use dynamic features
		     such as System.Reflection.Emit.

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

		     When using	a Mono that has	been compiled with  LLVM  sup-
		     port,  it	forces	Mono to	fallback to its	JIT engine and
		     not use the LLVM backend.

	      --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, be-
		     fore using	these flags  for  a  deployment	 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
		     elimination and inlining, you can use:
		     The flags that are	flagged	with  [arch-dependency]	 indi-
		     cate  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.

		     The following optimizations are supported

			    Requests that the runtime performn 32-bit floating
			    point  operations using only 32-bits.   By default
			    the	Mono runtime tries to use the  highest	preci-
			    sion  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 in-
			    line  (the default), or not	inline methods invoca-

		     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  op-
		     tion can be used to override such autodetection, by forc-
		     ing 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	 call-
		     ing 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,
			    light/  for	more details and links to the descrip-
			    tions of this new system.

			    Enables the	new verifier and performs basic	 veri-
			    fication  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.

			    Enables the	new verifier and performs full verifi-
			    cation 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  verifica-
			    tion  is not as strict as ECMA 335 standard	in or-
			    der	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.

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

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

		     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

	      -V, --version
		     Prints JIT	version	information (system configuration, re-
		     lease 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.

	      Loads  a	profiler module	with the given arguments. For more in-
	      formation, see the PROFILING section.  This option can  be  used
	      multiple	times; each time will load an additional profiler mod-

	      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 instruc-
	      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 API that dynamically loaded pro-
       filer modules and embedders can use to collect performance-related data
       about an	application. Profiler modules are loaded by passing the	--pro-
       file command line argument to the Mono runtime.

       Mono ships with a few profiler modules, of which	the  log  profiler  is
       the  most feature-rich. It is also the default profiler if the profiler
       argument	is not given, or if default is given.  It is possible to write
       your own	profiler modules; see the Custom profilers sub-section.

   Log profiler
       The  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	behav-
       ior, determine resource usage, performance issues or even look for par-
       ticular execution patterns.

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

       More  information about how to use the log profiler is available	on the
       mono-profilers(1) page, under the LOG PROFILER section, as well as  the
       mprof-report(1) page.

   Coverage profiler
       The  code  coverage profiler can	instrument a program to	help determine
       which classes, methods, code paths, etc are actually executed. This  is
       most  useful  when  running a test suite	to determine whether the tests
       actually	cover the code they're expected	to.

       More information	about how to use the coverage profiler is available on
       the mono-profilers(1) page, under the COVERAGE PROFILER section.

   AOT profiler
       The  AOT	profiler can help improve startup performance by logging which
       generic instantiations are used by a program, which  the	 AOT  compiler
       can then	use to compile those instantiations ahead of time so that they
       won't have to be	JIT compiled at	startup.

       More information	about how to use the AOT profiler is available on  the
       mono-profilers(1) page, under the AOT PROFILER section.

   Custom profilers
       Custom  profiler	 modules  can be loaded	in exactly the same way	as the
       standard	modules	that ship with Mono. They can  also  access  the  same
       profiler	 API  to  gather all kinds of information about	the code being

       For example, to use a third-party profiler  called  custom,  you	 would
       load it like this:

	      mono --profile=custom program.exe

       You could also pass arguments to	it:

	      mono --profile=custom:arg1,arg2=arg3 program.exe

       In  the	above example, Mono will load the profiler from	the shared li-
       brary called (name varies based on platform,
       e.g.,  libmono-profiler-custom.dylib  on	 OS  X).  This profiler	module
       must be on your dynamic linker library path  (LD_LIBRARY_PATH  on  most
       systems,	DYLD_LIBRARY_PATH on OS	X).

       For a sample of how to write your own custom profiler, look at the sam-
       ples/profiler/sample.c file in the Mono source tree.

       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-selector" (async	socket	opera-
       tions), "io-layer" (I/O layer - processes, files, sockets, events, sem-
       aphores,	mutexes	 and  handles),	 "io-layer-process",  "io-layer-file",
       "io-layer-socket",  "io-layer-event",  "io-layer-semaphore", "io-layer-
       mutex", "io-layer-handle" and  "all".   The  default  value  is	"all".
       Changing	 the mask value	allows you to display only messages for	a cer-
       tain 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.

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

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

		     Specifies what should be the garbage collector's  target.
		     The  `throughput'	mode  aims to reduce time spent	in the
		     garbage collector	and  improve  application  speed,  the
		     `pause' mode aims to keep pause times to a	minimum	and it
		     receives the argument max-pause which specifies the maxi-
		     mum pause time in milliseconds that is acceptable and the
		     `balanced'	mode which is a	general	purpose	optimal	mode.

		     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, `simple-par' which has same	promo-
		     tion  behavior as `simple'	but using multiple workers and
		     `split' which lets	objects	stay longer on the nursery be-
		     fore 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.

	      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	 crash
		     occurs (SIGSEGV, SIGILL, ...).  This is useful for	debug-
		     ging crashes which	do not happen under gdb, since a  live
		     process contains more information than a core file.

		     Same as suspend-on-native-crash.

		     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/local/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/local/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),  cert-sync(1),  csharp(1),  gacutil(1), mcs(1), monodis(1),
       mono-config(5), mono-profilers(1), mprof-report(1), pdb2mdb(1), xsp(1),

       For   more  information	on  AOT:

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



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

home | help