1Mono(Mono 2.5) Mono(Mono 2.5)
2
6 mono - Mono's ECMA-CLI native code generator (Just-in-Time and Ahead-
7 of-Time)
8
10 mono [options] file [arguments...]
11
13 mono is a runtime implementation of the ECMA Common Language Infra‐
14 structure. This can be used to run ECMA and .NET applications.
15 The runtime contains a native code generator that transforms the Common
17 Intermediate Language into native code.
18 The code generator can operate in two modes: just in time compilation
20 (JIT) or ahead of time compilation (AOT). Since code can be dynami‐
21 cally loaded, the runtime environment and the JIT are always present,
22 even if code is compiled ahead of time.
23 The runtime loads the specified file and optionally passes the argu‐
25 ments to it. The file is an ECMA assembly. They typically have a .exe
26 or .dll extension.
27 The runtime provides a number of configuration options for running
29 applications, for developing and debugging, and for testing and debug‐
30 ging the runtime itself.
31
33 On Unix-based systems, Mono provides a mechanism to emulate the Win‐
34 dows-style file access, this includes providing a case insensitive view
35 of the file system, directory separator mapping (from \ to /) and
36 stripping the drive letters.
37 This functionality is enabled by setting the MONO_IOMAP environment
39 variable to one of all, drive and case.
40 See the description for MONO_IOMAP in the environment variables section
42 for more details.
43
45 The following options are available:
46 --aot, --aot[=options]
48 This option is used to precompile the CIL code in the specified
49 assembly to native code. The generated code is stored in a file
50 with the extension .so. This file will be automatically picked
51 up by the runtime when the assembly is executed. Ahead-of-Time
52 compilation is most useful if you use it in combination with the
53 -O=all,-shared flag which enables all of the optimizations in
54 the code generator to be performed. Some of those optimizations
55 are not practical for Just-in-Time compilation since they might
56 be very time consuming. Unlike the .NET Framework, Ahead-of-
57 Time compilation will not generate domain independent code: it
58 generates the same code that the Just-in-Time compiler would
59 produce. Since most applications use a single domain, this is
60 fine. If you want to optimize the generated code for use in
61 multi-domain applications, consider using the -O=shared flag.
62 This pre-compiles the methods, but the original assembly is
63 still required to execute as this one contains the metadata and
64 exception information which is not available on the generated
65 file. When precompiling code, you might want to compile with
66 all optimizations (-O=all). Pre-compiled code is position inde‐
67 pendent code. Pre compilation is just a mechanism to reduce
68 startup time, increase code sharing across multiple mono pro‐
69 cesses and avoid just-in-time compilation program startup costs.
70 The original assembly must still be present, as the metadata is
71 contained there. AOT code typically can not be moved from one
72 computer to another (CPU-specific optimizations that are
73 detected at runtime) so you should not try to move the pre-gen‐
74 erated assemblies or package the pre-generated assemblies for
75 deployment. A few options are available as a parameter to the
76 --aot command line option. The options are separated by com‐
77 mas, and more than one can be specified:
78 bind-to-runtime-version
80 If specified, forces the generated AOT files to be bound
81 to the runtime version of the compiling Mono. This will
82 prevent the AOT files from being consumed by a different
83 Mono runtime. full This is currently an experimental
84 feature as it is not complete. This instructs Mono to
85 precompile code that has historically not been precom‐
86 piled with AOT.
87 outfile=[filename]
89 Instructs the AOT compiler to save the output to the
90 specified file.
91 write-symbols
93 Instructs the AOT compiler to emit debug symbol informa‐
94 tion.
95 save-temps,keep-temps
97 Instructs the AOT compiler to keep temporary files.
98 threads=[number]
100 This is an experimental option for the AOT compiler to
101 use multiple threads when compiling the methods.
102 nodebug
104 Instructs the AOT compiler to not output any debugging
105 information.
106 ntrampolines=[number]
108 When compiling in full aot mode, the method trampolines
109 must be precreated in the AOT image. You can add addi‐
110 tional method trampolines with this argument. Defaults
111 to 1024.
112 nrgctx-trampolines=[number]
114 When compiling in full aot mode, the generic sharing
115 trampolines must be precreated in the AOT image. You can
116 add additional method trampolines with this argument.
117 Defaults to 1024.
118 nimt-trampolines=[number]
120 When compiling in full aot mode, the IMT trampolines must
121 be precreated in the AOT image. You can add additional
122 method trampolines with this argument. Defaults to 128.
123 print-skipped-methods
125 If the AOT compiler cannot compile a method for any rea‐
126 son, enabling this flag will output the skipped methods
127 to the console.
128 autoreg
130 The AOT compiler will emit a (ELF only) library initial‐
131 izer to automatically register the aot compiled module
132 with the runtime. This is only useful in static mode
133 asmonly
135 Instructs the AOT compiler to output assembly code
136 instead of an object file.
137 soft-debug
139 This instructs the compiler to generate sequence point
140 checks that allow Mono's soft debugger to debug applica‐
141 tions even on systems where it is not possible to set
142 breakpoints or to single step (certain hardware configu‐
143 rations like the cell phones and video gaming consoles).
144 static Create an ELF object file (.o) which can be statically
146 linked into an executable when embedding the mono run‐
147 time. When this option is used, the object file needs to
148 be registered with the embedded runtime using the
149 mono_aot_register_module function which takes as its
150 argument the mono_aot_module_<ASSEMBLY NAME>_info global
151 symbol from the object file:
152 extern void *mono_aot_module_hello_info;
154 mono_aot_register_module (mono_aot_module_hello_info);
156 For more information about AOT, see: http://www.mono-
159 project.com/AOT
160 --attach=[options]
162 Currently the only option supported by this command line argu‐
163 ment is disable which disables the attach functionality.
164 --full-aot
166 This is an experimental flag that instructs the Mono runtime to
167 not generate any code at runtime and depend exclusively on the
168 code generated from using mono --aot=full previously. This is
169 useful for platforms that do not permit dynamic code generation.
170 Notice that this feature will abort execution at runtime if a
171 codepath in your program, or Mono's class libraries attempts to
172 generate code dynamically. You should test your software
173 upfront and make sure that you do not use any dynamic features.
174 --config filename
176 Load the specified configuration file instead of the default
177 one(s). The default files are /etc/mono/config and ~/.mono/con‐
178 fig or the file specified in the MONO_CONFIG environment vari‐
179 able, if set. See the mono-config(5) man page for details on
180 the format of this file.
181 --desktop
183 Configures the virtual machine to be better suited for desktop
184 applications. Currently this sets the GC system to avoid
185 expanding the heap as much as possible at the expense of slowing
186 down garbage collection a bit.
187 --help, -h
189 Displays usage instructions.
190 --optimize=MODE, -O=MODE
192 MODE is a comma separated list of optimizations. They also
193 allow optimizations to be turned off by prefixing the optimiza‐
194 tion name with a minus sign. In general, Mono has been tuned to
195 use the default set of flags, before using these flags for a
196 deployment setting, you might want to actually measure the bene‐
197 fits of using them. The following optimizations are imple‐
198 mented:
199 all Turn on all optimizations
200 peephole Peephole postpass
201 branch Branch optimizations
202 inline Inline method calls
203 cfold Constant folding
204 consprop Constant propagation
205 copyprop Copy propagation
206 deadce Dead code elimination
207 linears Linear scan global reg allocation
208 cmov Conditional moves [arch-dependency]
209 shared Emit per-domain code
210 sched Instruction scheduling
211 intrins Intrinsic method implementations
212 tailc Tail recursion and tail calls
213 loop Loop related optimizations
214 fcmov Fast x86 FP compares [arch-dependency]
215 leaf Leaf procedures optimizations
216 aot Usage of Ahead Of Time compiled code
217 precomp Precompile all methods before executing Main
218 abcrem Array bound checks removal
219 ssapre SSA based Partial Redundancy Elimination
220 sse2 SSE2 instructions on x86 [arch-dependency]
221 gshared Enable generic code sharing.
222 For example, to enable all the optimization but dead code elimi‐
223 nation and inlining, you can use:
224 -O=all,-deadce,-inline
225 The flags that are flagged with [arch-dependency] indicate that
226 the given option if used in combination with Ahead of Time com‐
227 pilation (--aot flag) would produce pre-compiled code that will
228 depend on the current CPU and might not be safely moved to
229 another computer.
230 --runtime=VERSION
232 Mono supports different runtime versions. The version used
233 depends on the program that is being run or on its configuration
234 file (named program.exe.config). This option can be used to
235 override such autodetection, by forcing a different runtime ver‐
236 sion to be used. Note that this should only be used to select a
237 later compatible runtime version than the one the program was
238 compiled against. A typical usage is for running a 1.1 program
239 on a 2.0 version:
240 mono --runtime=v2.0.50727 program.exe
241 --security, --security=mode
243 Activate the security manager, a currently experimental feature
244 in Mono and it is OFF by default. The new code verifier can be
245 enabled with this option as well.
246 Using security without parameters is equivalent as calling it
248 with the "cas" parameter.
249 The following modes are supported:
251 cas This allows mono to support declarative security
253 attributes, e.g. execution of Code Access Security (CAS)
254 or non-CAS demands.
255 core-clr
257 Enables the core-clr security system, typically used for
258 Moonlight/Silverlight applications. It provides a much
259 simpler security system than CAS, see http://www.mono-
260 project.com/Moonlight for more details and links to the
261 descriptions of this new system.
262 validil
264 Enables the new verifier and performs basic verification
265 for code validity. In this mode, unsafe code and
266 P/Invoke are allowed. This mode provides a better safety
267 guarantee but it is still possible for managed code to
268 crash Mono.
269 verifiable
271 Enables the new verifier and performs full verification
272 of the code being executed. It only allows verifiable
273 code to be executed. Unsafe code is not allowed but
274 P/Invoke is. This mode should not allow managed code to
275 crash mono. The verification is not as strict as ECMA
276 335 standard in order to stay compatible with the MS run‐
277 time.
278 The security system acts on user code: code contained in mscor‐
280 lib or the global assembly cache is always trusted.
281 --server
283 Configures the virtual machine to be better suited for server
284 operations (currently, a no-op).
285 --verify-all
287 Verifies mscorlib and assemblies in the global assembly cache
288 for valid IL, and all user code for IL verifiability.
289 This is different from --security's verifiable or validil in
291 that these options only check user code and skip mscorlib and
292 assemblies located on the global assembly cache.
293 -V, --version
295 Prints JIT version information (system configuration, release
296 number and branch names if available).
297
301 The following options are used to help when developing a JITed applica‐
302 tion.
303 --debug, --debug=OPTIONS
305 Turns on the debugging mode in the runtime. If an assembly was
306 compiled with debugging information, it will produce line number
307 information for stack traces.
308 The optional OPTIONS argument is a comma separated list of
310 debugging options. These options are turned off by default
311 since they generate much larger and slower code at runtime.
312 The following options are supported:
314 casts Produces a detailed error when throwing a InvalidCastEx‐
316 ception. This option needs to be enabled as this gener‐
317 ates more verbose code at execution time.
318 mdb-optimizations
320 Disable some JIT optimizations which are usually only
321 disabled when running inside the debugger. This can be
322 helpful if you want to attach to the running process with
323 mdb.
324 gdb Generate and register debugging information with gdb.
326 This is only supported on some platforms, and only when
327 using gdb 7.0 or later.
328 --profile[=profiler[:profiler_args]]
330 Turns on profiling. For more information about profiling appli‐
331 cations and code coverage see the sections "PROFILING" and "CODE
332 COVERAGE" below.
333 --trace[=expression]
335 Shows method names as they are invoked. By default all methods
336 are traced. The trace can be customized to include or exclude
337 methods, classes or assemblies. A trace expression is a comma
338 separated list of targets, each target can be prefixed with a
339 minus sign to turn off a particular target. The words `pro‐
340 gram', `all' and `disabled' have special meaning. `program'
341 refers to the main program being executed, and `all' means all
342 the method calls. The `disabled' option is used to start up
343 with tracing disabled. It can be enabled at a later point in
344 time in the program by sending the SIGUSR2 signal to the run‐
345 time. Assemblies are specified by their name, for example, to
346 trace all calls in the System assembly, use:
347 mono --trace=System app.exe
349 Classes are specified with the T: prefix. For example, to trace
351 all calls to the System.String class, use:
352 mono --trace=T:System.String app.exe
354 And individual methods are referenced with the M: prefix, and
356 the standard method notation:
357 mono --trace=M:System.Console:WriteLine app.exe
359 As previously noted, various rules can be specified at once:
361 mono --trace=T:System.String,T:System.Random app.exe
363 You can exclude pieces, the next example traces calls to Sys‐
365 tem.String except for the System.String:Concat method.
366 mono --trace=T:System.String,-M:System.String:Concat
368 Finally, namespaces can be specified using the N: prefix:
370 mono --trace=N:System.Xml
372 --no-x86-stack-align
375 Don't align stack frames on the x86 architecture. By default,
376 Mono aligns stack frames to 16 bytes on x86, so that local
377 floating point and SIMD variables can be properly aligned. This
378 option turns off the alignment, which usually saves one intruc‐
379 tion per call, but might result in significantly lower floating
380 point and SIMD performance.
381
383 The maintainer options are only used by those developing the runtime
384 itself, and not typically of interest to runtime users or developers.
385 --break method
387 Inserts a breakpoint before the method whose name is `method'
388 (namespace.class:methodname). Use `Main' as method name to
389 insert a breakpoint on the application's main method.
390 --breakonex
392 Inserts a breakpoint on exceptions. This allows you to debug
393 your application with a native debugger when an exception is
394 thrown.
395 --compile name
397 This compiles a method (namespace.name:methodname), this is used
398 for testing the compiler performance or to examine the output of
399 the code generator.
400 --compileall
402 Compiles all the methods in an assembly. This is used to test
403 the compiler performance or to examine the output of the code
404 generator
405 --graph=TYPE METHOD
407 This generates a postscript file with a graph with the details
408 about the specified method (namespace.name:methodname). This
409 requires `dot' and ghostview to be installed (it expects Ghost‐
410 view to be called "gv"). The following graphs are available:
411 cfg Control Flow Graph (CFG)
412 dtree Dominator Tree
413 code CFG showing code
414 ssa CFG showing code after SSA translation
415 optcode CFG showing code after IR optimizations
416 Some graphs will only be available if certain optimizations are
417 turned on.
418 --ncompile
420 Instruct the runtime on the number of times that the method
421 specified by --compile (or all the methods if --compileall is
422 used) to be compiled. This is used for testing the code genera‐
423 tor performance.
424 --stats
426 Displays information about the work done by the runtime during
427 the execution of an application.
428 --wapi=hps|semdel
430 Perform maintenance of the process shared data. semdel will
431 delete the global semaphore. hps will list the currently used
432 handles.
433 -v, --verbose
435 Increases the verbosity level, each time it is listed, increases
436 the verbosity level to include more information (including, for
437 example, a disassembly of the native code produced, code selec‐
438 tor info etc.).
439
441 The Mono runtime allows external processes to attach to a running
442 process and load assemblies into the running program. To attach to
443 the process, a special protocol is implemented in the Mono.Management
444 assembly.
445 With this support it is possible to load assemblies that have an entry
447 point (they are created with -target:exe or -target:winexe) to be
448 loaded and executed in the Mono process.
449 The code is loaded into the root domain, and it starts execution on the
451 special runtime attach thread. The attached program should create
452 its own threads and return after invocation.
453 This support allows for example debugging applications by having the
455 csharp shell attach to running processes.
456
458 The mono runtime includes a profiler that can be used to explore vari‐
459 ous performance related problems in your application. The profiler is
460 activated by passing the --profile command line argument to the Mono
461 runtime, the format is:
462 --profile[=profiler[:profiler_args]]
464 Mono has a built-in profiler called 'default' (and is also the default
466 if no arguments are specified), but developers can write custom profil‐
467 ers, see the section "CUSTOM PROFILERS" for more details.
468 If a profiler is not specified, the default profiler is used. The pro‐
470 filer_args is a profiler-specific string of options for the profiler
471 itself. The default profiler accepts the following options 'alloc' to
472 profile memory consumption by the application; 'time' to profile the
473 time spent on each routine; 'jit' to collect time spent JIT-compiling
474 methods and 'stat' to perform sample statistical profiling. If no
475 options are provided the default is 'alloc,time,jit'.
476 By default the profile data is printed to stdout: to change this, use
478 the 'file=filename' option to output the data to filename. For exam‐
479 ple:
480 mono --profile program.exe
482 That will run the program with the default profiler and will do time
484 and allocation profiling.
485 mono --profile=default:stat,alloc,file=prof.out program.exe
487 Will do sample statistical profiling and allocation profiling on pro‐
489 gram.exe. The profile data is put in prof.out. Note that the statisti‐
490 cal profiler has a very low overhead and should be the preferred pro‐
491 filer to use (for better output use the full path to the mono binary
492 when running and make sure you have installed the addr2line utility
493 that comes from the binutils package).
494
496 The logging profiler is a general purpose profiler that can track many
497 different kinds of events and logs those into a file as the program
498 executes. This is different than previous profilers in Mono that kept
499 the information in memory and rendered a summary of the results when
500 the program shut down.
501 Using the logging profiler means that useful information can be gath‐
503 ered for long-running applications, applications that terminate abor‐
504 mally (crashes, segfaults, complicated tear down processes) or when no
505 data about the shutdown is required.
506 The data collected by the running threads is kept independent of each
508 other to minimize the runtime overhead and the information dumped into
509 the log at regular intervals.
510 A sample use is very simple:
512 $ mono --profile=logging program.exe
513 $ mprof-decoder program.mprof
515 In the above example the logging profiler is used in its default mode
517 that merely records GC statistics for the execution of program.exe.
518 The profiling data collected is stored in the file program.mprof. The
519 mprof-decoder tool is then used to analyze the data.
520 You can instruct the logging profiler to record different one or more
522 sets of events. These are the modes supported:
523 Statistical Profiling (stat) the program instruction pointer is
525 periodically sampled to determine where the program is spending
526 most of its time. Statistical profiling has a very low impact
527 on a running application and it is very useful to get a general
528 picture of where time is being spent on a program.
529 If call chains are requested, for each sample the profiler gets
531 a partial stack trace (limited by the specified depth) so that
532 caller-callee information is available.
533 Instrumenting: each method enter and exit is logged with a time‐
535 stamp; further processing of the data can show the methods that
536 took the longer to execute, with complete accounting for callers
537 and callees. However, this way of profiling is rather intrusive
538 and slows down the application significantly.
539 Allocation: each allocation is logged.
541 Allocation summary: shows, for each collection, a summary of the
543 heap contents broken down by class (for each class the number of
544 allocated and released objects is given, together with their
545 aggregated size in bytes).
546 Heap snapshot mode: dumps the whole heap contents at every col‐
548 lection (or at user specified collections). It is also possible
549 to request a collection and snapshot dump with a signal.
550 Moreover, other events can be logged and analyzed, like jit time for
552 each method, load and unload for assemblies, modules and and individual
553 classes, and appdomain and thread creation and destruction.
554 This profiler is activated passing the --profile=logging option to the
556 mono runtime, and is controlled attaching further options, like --pro‐
557 file=logging:statistical for doing statistical profiling (multiple
558 options are separated by commas).
559 As a quick primer, here are a few examples of the most common usage
561 modes:
562 To perform statistical profiling:
564 mono --profile=logging:stat program.exe
566 To perform statistical profiling, inspecting call chains up to depth 8:
568 mono --profile=logging:stat=8 program.exe
570 To profile allocations (by default the call stack will be analized for
572 each allocation, producing detailed caller method attribution inforna‐
573 tion):
574 mono --profile=logging:allocations program.exe
576 To profile garbage collection activity at a high level (collection time
578 and objects freed at each collection for each class are reported, but
579 heap snapshots are not saved to disk):
580 mono --profile=logging:allocations-summary program.exe
582 To perform heap profiling taking heap snapshots:
584 mono --profile=logging:heap=all program.exe
586 To write the resulting data to a different file:
588 mono --profile=logging:output=mydata.mprof program.exe
590 Then you would need to invoke the decoder mprof-decoder(1) on the out‐
592 put file to see the profiling results, or to examine heap snapshots and
593 allocations in detail mprof-heap-viewer(1).
594 The operating modes described above are the default ones, and are suf‐
596 ficient to use the profiler.
597 To further customize the profiler behavior there are more options,
599 described below.
600 These options can be individually enabled and disabled prefixing them
602 with an (optional) '+' character or a '-' character. For instance, the
603 "allocations" option by default records also the full call stack at
604 each allocation. If only the caller is wanted, one should use "alloca‐
605 tions,-save-allocation-stack", or to disable call tracking completely
606 (making the profiler less intrusive) "allocations,-save-allocation-
607 caller,-save-allocation-stack". In practice the "allocation" option by
608 default behaves like "allocations,save-allocation-caller,save-alloca‐
609 tion-stack", but the user can tune this to his needs.
610 These are all the available options, organized by category:
612 Execution profiling modes
614 statistical, stat or s
616 Performs statistical profiling. This is a lightweight
617 profiling mechanism and it has a much lower overhead than
618 the enter-leave profiling as it works by sampling where
619 the program is spending its time by using a timer. If
620 specified with s=<number>, also inspect call chains up to
621 level <number>.
622 enter-leave, calls or c
624 Measure the time spent inside each method call, this is
625 done by logging the time when a method enters and when
626 the method leaves. This can be a time consuming opera‐
627 tion.
628 jit, j Collect information about time spent by the JIT engine
630 compiling methods.
631 Allocation profiling modes
633 allocations, alloc or a
635 Collect information about each allocation (object class
636 and size). By default this also implies "+save-alloca‐
637 tion-caller" and "+save-allocation-stack".
638 save-allocation-caller, sac
640 Save the direct caller of each allocation. The profiler
641 filters out wrapper methods, and also recognizes if the
642 allocation has been performed by the runtime while jit‐
643 ting a method.
644 save-allocation-stack, sas
646 Save the full managed execution stack at each allocation.
647 While the "sac" option saves the direct caller, this one
648 records the whole stack trace. Note that in the call
649 stack the wrapper methods are not filtered out. Anyway
650 the "sac" and "sas" options can be combined, and the
651 decoder will attribute the allocation to the correct
652 method even if the wrapper is at the top of the stack
653 trace.
654 allocations-summary or as
656 At each collection dump a summary of the heap contents
657 (for each class, the number and collective size of all
658 live and freed heap objects). This very lightweight com‐
659 pared to full heap snapshots.
660 unreachable, free or f
662 Performs a lightweight profile of the garbage collector.
663 On each collection performed by the GC, the list of
664 unreachable objects is recorded, and for each object the
665 class and size is provided. This information can be used
666 to compute the heap size broken down by class (combined
667 with "a" can give the same information of "as", but the
668 log file contains info about each individual object,
669 while in "as" the processing is done directly at runtime
670 and the log file contains only the summarized data broken
671 down by class).
672 gc or g
674 Measure the time spent in each collection, and also trace
675 heap resizes.
676 heap-shot[=ARG], heap[=ARG] or h[=ARH]
678 Performs full heap profiling. In this case on each col‐
679 lection a full heap snapshot is recorded to disk. Inside
680 the snapshots, each object reference is still represented
681 so that it's possible to investigate who is responsible
682 for keeping objects alive.
683 If the value of ARG is all, a heap snapshot is taken at each
685 collection.
686 If the value is an integer n, a snapshot will be taken at the
688 first n collections (like setting gcd=n );
689 If no additional argument is given to the heap option, the only
691 way to take heap snapshots is to requeste them using the runtime
692 socket based command interface described below (see "Profiler
693 activity control").
694 Heap profiling also enables full allocation profiling (with call
696 stacks), and each allocation can be related to its corresponding
697 object in the snapshots, enabling investigations like "find all
698 objects of a given class allocated by a given method and still
699 live at a given collection, and then find all objects referenc‐
700 ing them".
701 This kind of heap snapshot analysis is performed using the
703 mprof-heap-viewer(1) application.
704 The number of heap snapshots taken (and the moment in which they
706 are taken) can be further customized with the following options:
707 gc-dumps=N, gc-d=N, gcd=N
709 states the number of snapshots that must be dumped (since
710 the application starts). Zero means no dumps at all, -1
711 means dump at all collections.
712 These options exist because it can happen that the user wants to
714 investigate
715 what happens during collections but without forcing a
716 collection using the command interface, because forcing a
717 collection alters the program behavior. Of course it is
718 possible to simply take a snapshot at every collection,
719 but in some workloads this is could not be feasible (too
720 much data). So we have this "garbage collection dumps"
721 counter to control how many snapshots to take.
722 Profiler activity control
724 output=FILE, out=FILE or o=FILE
726 Use this option to provide the output file name for the
727 profile log. If this option is not specified, it will
728 default to "<program-name>.mprof".
729 output-suffix=SUFFIX, suffix=SUFFIX or os=SUFFIX: makes
731 the output file name equals to "<program-name>-SUF‐
732 FIX.mprof".
733 start-enabled or se: start with the profiler active
735 (which is the default).
736 start-disabled or sd: start with the profiler inactive.
738 force-accurate-timer (or fac): the profiler by default uses
740 rtdsc to acquire timestamps for frequent events, but this
741 can be imprecise; using this option you force the use of
742 "gettimeofday" at every event, which is more accurate but
743 much slower.
744 command-port=port or cp=port (where port is an integer between
746 1024 nd 65535): Choose a TCP port where the profiler will
747 listen for user commands. The protocol is ASCII based
748 and line oriented (one line per command), and the pro‐
749 filer answers with one line containing either "OK" or
750 "ERROR" to each received command.
751 The user can telnet to this port and give commands manually, or
753 a GUI can use this facility to control the profiler at runtime.
754 The available commands are:
756 enable: Enables the profiler.
758 disable: Disables the profiler.
760 heap-snapshot: Takes a heap snapshot now (forces a full garbage
762 collection).
763 heap-snapshot-counter=arg: Set the counter of the next heap
765 snapshots
766 that must be taken, where arg can be "all" (take a snap‐
767 shot at every collection), "none" (do not take snap‐
768 shots), or an integer "n" (take a heap snapshot for the
769 next "n" collections).
770 Internal buffer sizes
772 per-thread-buffer-size=N, tbs=N
774 Use to specify the number of events that a thread buffer
775 can hold. When the thread buffer is full, a log block
776 is written to disk. This defaults to tbs=10000.
777 statistical-thread-buffer-size=N, sbs=N
779 The number of statistical samples that are held in memory
780 before they are dumped to disk (the system does double-
781 buffering and the statistical samples are written by a
782 helper thread, so the statistical profiler never stops
783 and is able to profile the profiler itself). This
784 defaults to sbs=10000.
785 write-buffer-size, wbs
787 Specifies the size in bytes of the internal write buf‐
788 fers. This defaults to wbs=1024.
789 In its current state, this profiler can also perform heap analysis like
791 the HeapShot profiler, but there is no UI to process this information.
792 Another known issue is that if the timer is not strictly monotonic
794 (like rtdsc), differences between times can underflow (they are handled
795 as unsigned integers) and weird numbers can show up in the logs.
796 Finally, it can happen that when exceptions are thrown the profiler
798 temporarily loses track of the execution stack and misattributes the
799 caller for a few allocations (and method execution time).
800 The output file contains compressed events, to process the data you
802 should use tools like the "Mono.Profiler" tool provided on the Mono SVN
803 repository.
804 More explanations are provided here: "http://www.mono-project.com/Log‐
806 gingProfiler".
807
809 There are a number of external profilers that have been developed for
810 Mono, we will update this section to contain the profilers.
811 The heap Shot profiler can track all live objects, and references to
813 these objects, and includes a GUI tool, this is our recommended pro‐
814 filer. To install you must download the profiler from Mono's SVN:
815 svn co svn://anonsvn.mono-project.com/source/trunk/heap-shot
816 cd heap-shot
817 ./autogen
818 make
819 make install
820 See the included documentation for details on using it.
822 The Live Type profiler shows at every GC iteration all of the live
824 objects of a given type. To install you must download the profiler
825 from Mono's SVN:
826 svn co svn://anonsvn.mono-project.com/source/trunk/heap-prof
827 cd heap-prof
828 ./autogen
829 make
830 make install
831 To use the profiler, execute:
833 mono --profile=desc-heap program.exe
834 The output of this profiler looks like this:
836 Checkpoint at 102 for heap-resize
837 System.MonoType : 708
838 System.Threading.Thread : 352
839 System.String : 3230
840 System.String[] : 104
841 Gnome.ModuleInfo : 112
842 System.Object[] : 160
843 System.Collections.Hashtable : 96
844 System.Int32[] : 212
845 System.Collections.Hashtable+Slot[] : 296
846 System.Globalization.CultureInfo : 108
847 System.Globalization.NumberFormatInfo : 144
848 The first line describes the iteration number for the GC, in this case
850 checkpoint 102.
851 Then on each line the type is displayed as well as the number of bytes
853 that are being consumed by live instances of this object.
854 The AOT profiler is used to feed back information to the AOT compiler
856 about how to order code based on the access patterns for pages. To use
857 it, use:
858 mono --profile=aot program.exe
859 The output of this profile can be fed back into Mono's AOT compiler to
860 order the functions on the disk to produce precompiled images that have
861 methods in sequential pages.
862
864 Mono provides a mechanism for loading other profiling modules which in
865 the form of shared libraries. These profiling modules can hook up to
866 various parts of the Mono runtime to gather information about the code
867 being executed.
868 To use a third party profiler you must pass the name of the profiler to
870 Mono, like this:
871 mono --profile=custom program.exe
873 In the above sample Mono will load the user defined profiler from the
876 shared library `mono-profiler-custom.so'. This profiler module must be
877 on your dynamic linker library path.
878 A list of other third party profilers is available from Mono's web site
880 (www.mono-project.com/Performance_Tips)
881 Custom profiles are written as shared libraries. The shared library
883 must be called `mono-profiler-NAME.so' where `NAME' is the name of your
884 profiler.
885 For a sample of how to write your own custom profiler look in the Mono
887 source tree for in the samples/profiler.c.
888
890 Mono ships with a code coverage module. This module is activated by
891 using the Mono --profile=cov option. The format is: --pro‐
892 file=cov[:assembly-name[/namespace]] test-suite.exe
893 By default code coverage will default to all the assemblies loaded, you
895 can limit this by specifying the assembly name, for example to perform
896 code coverage in the routines of your program use, for example the fol‐
897 lowing command line limits the code coverage to routines in the "demo"
898 assembly:
899 mono --profile=cov:demo demo.exe
901 Notice that the assembly-name does not include the extension.
904 You can further restrict the code coverage output by specifying a
906 namespace:
907 mono --profile=cov:demo/My.Utilities demo.exe
909 Which will only perform code coverage in the given assembly and names‐
912 pace.
913 Typical output looks like this:
915 Not covered: Class:.ctor ()
917 Not covered: Class:A ()
918 Not covered: Driver:.ctor ()
919 Not covered: Driver:method ()
920 Partial coverage: Driver:Main ()
921 offset 0x000a
922 The offsets displayed are IL offsets.
925 A more powerful coverage tool is available in the module `monocov'.
927 See the monocov(1) man page for details.
928
930 To debug managed applications, you can use the mdb command, a command
931 line debugger.
932 It is possible to obtain a stack trace of all the active threads in
934 Mono by sending the QUIT signal to Mono, you can do this from the com‐
935 mand line, like this:
936 kill -QUIT pid
938 Where pid is the Process ID of the Mono process you want to examine.
940 The process will continue running afterwards, but its state is not
941 guaranteed.
942 Important: this is a last-resort mechanism for debugging applications
944 and should not be used to monitor or probe a production application.
945 The integrity of the runtime after sending this signal is not guaran‐
946 teed and the application might crash or terminate at any given point
947 afterwards.
948 The --debug=casts option can be used to get more detailed information
950 for Invalid Cast operations, it will provide information about the
951 types involved.
952 You can use the MONO_LOG_LEVEL and MONO_LOG_MASK environment variables
954 to get verbose debugging output about the execution of your application
955 within Mono.
956 The MONO_LOG_LEVEL environment variable if set, the logging level is
958 changed to the set value. Possible values are "error", "critical",
959 "warning", "message", "info", "debug". The default value is "error".
960 Messages with a logging level greater then or equal to the log level
961 will be printed to stdout/stderr.
962 Use "info" to track the dynamic loading of assemblies.
964 Use the MONO_LOG_MASK environment variable to limit the extent of the
966 messages you get: If set, the log mask is changed to the set value.
967 Possible values are "asm" (assembly loader), "type", "dll" (native
968 library loader), "gc" (garbage collector), "cfg" (config file loader),
969 "aot" (precompiler) and "all". The default value is "all". Changing
970 the mask value allows you to display only messages for a certain compo‐
971 nent. You can use multiple masks by comma separating them. For example
972 to see config file messages and assembly loader messages set you mask
973 to "asm,cfg".
974 The following is a common use to track down problems with P/Invoke:
976 $ MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono glue.exe
978
981 Mono's XML serialization engine by default will use a reflection-based
982 approach to serialize which might be slow for continuous processing
983 (web service applications). The serialization engine will determine
984 when a class must use a hand-tuned serializer based on a few parameters
985 and if needed it will produce a customized C# serializer for your types
986 at runtime. This customized serializer then gets dynamically loaded
987 into your application.
988 You can control this with the MONO_XMLSERIALIZER_THS environment vari‐
990 able.
991 The possible values are `no' to disable the use of a C# customized
993 serializer, or an integer that is the minimum number of uses before the
994 runtime will produce a custom serializer (0 will produce a custom seri‐
995 alizer on the first access, 50 will produce a serializer on the 50th
996 use). Mono will fallback to an interpreted serializer if the serializer
997 generation somehow fails. This behavior can be disabled by setting the
998 option `nofallback' (for example: MONO_XMLSERIALIZER_THS=0,nofallback).
999
1001 GC_DONT_GC
1002 Turns off the garbage collection in Mono. This should be only
1003 used for debugging purposes
1004 LVM_COUNT
1006 When Mono is compiled with LLVM support, this instructs the run‐
1007 time to stop using LLVM after the specified number of methods
1008 are JITed. This is a tool used in diagnostics to help isolate
1009 problems in the code generation backend. For example
1010 LLVM_COUNT=10 would only compile 10 methods with LLVM and then
1011 switch to the Mono JIT engine. LLVM_COUNT=0 would disable the
1012 LLVM engine altogether.
1013 MONO_AOT_CACHE
1015 If set, this variable will instruct Mono to ahead-of-time com‐
1016 pile new assemblies on demand and store the result into a cache
1017 in ~/.mono/aot-cache.
1018 MONO_CFG_DIR
1020 If set, this variable overrides the default system configuration
1021 directory ($PREFIX/etc). It's used to locate machine.config
1022 file.
1023 MONO_COM
1025 Sets the style of COM interop. If the value of this variable is
1026 "MS" Mono will use string marhsalling routines from the
1027 liboleaut32 for the BSTR type library, any other values will use
1028 the mono-builtin BSTR string marshalling.
1029 MONO_CONFIG
1031 If set, this variable overrides the default runtime configura‐
1032 tion file ($PREFIX/etc/mono/config). The --config command line
1033 options overrides the environment variable.
1034 MONO_DEBUG
1036 If set, enables some features of the runtime useful for debug‐
1037 ging. This variable should contain a comma separated list of
1038 debugging options. Currently, the following options are sup‐
1039 ported:
1040 break-on-unverified
1042 If this variable is set, when the Mono VM runs into a
1043 verification problem, instead of throwing an exception it
1044 will break into the debugger. This is useful when debug‐
1045 ging verifier problems
1046 collect-pagefault-stats
1048 Collects information about pagefaults. This is used
1049 internally to track the number of page faults produced to
1050 load metadata. To display this information you must use
1051 this option with "--stats" command line option.
1052 dont-free-domains
1054 This is an Optimization for multi-AppDomain applications
1055 (most commonly ASP.NET applications). Due to internal
1056 limitations Mono, Mono by default does not use typed
1057 allocations on multi-appDomain applications as they could
1058 leak memory when a domain is unloaded. Although this is
1059 a fine default, for applications that use more than on
1060 AppDomain heavily (for example, ASP.NET applications) it
1061 is worth trading off the small leaks for the increased
1062 performance (additionally, since ASP.NET applications are
1063 not likely going to unload the application domains on
1064 production systems, it is worth using this feature).
1065 handle-sigint
1067 Captures the interrupt signal (Control-C) and displays a
1068 stack trace when pressed. Useful to find out where the
1069 program is executing at a given point. This only dis‐
1070 plays the stack trace of a single thread.
1071 keep-delegates
1073 This option will leak delegate trampolines that are no
1074 longer referenced as to present the user with more infor‐
1075 mation about a delegate misuse. Basically a delegate
1076 instance might be created, passed to unmanaged code, and
1077 no references kept in managed code, which will garbage
1078 collect the code. With this option it is possible to
1079 track down the source of the problems.
1080 no-gdb-backtrace
1082 This option will disable the GDB backtrace emitted by the
1083 runtime after a SIGSEGV or SIGABRT in unmanaged code.
1084 suspend-on-sigsegv
1086 This option will suspend the program when a native
1088 SIGSEGV is received. This is useful for debugging
1089 crashes which do not happen under gdb, since a live
1090 process contains more information than a core file.
1091 MONO_DISABLE_AIO
1093 If set, tells mono NOT to attempt using native asynchronous I/O
1094 services. In that case, a default select/poll implementation is
1095 used. Currently only epoll() is supported.
1096 MONO_DISABLE_MANAGED_COLLATION
1098 If this environment variable is `yes', the runtime uses unman‐
1099 aged collation (which actually means no culture-sensitive colla‐
1100 tion). It internally disables managed collation functionality
1101 invoked via the members of System.Globalization.CompareInfo
1102 class. Collation is enabled by default.
1103 MONO_EGD_SOCKET
1105 For platforms that do not otherwise have a way of obtaining ran‐
1106 dom bytes this can be set to the name of a file system socket on
1107 which an egd or prngd daemon is listening.
1108 MONO_EVENTLOG_TYPE
1110 Sets the type of event log provider to use (for System.Diagnos‐
1111 tics.EventLog). Possible values are:
1112 local[:path]
1114 Persists event logs and entries to the local file system.
1115 The directory in which to persist the event logs, event
1116 sources and entries can be specified as part of the
1117 value. If the path is not explicitly set, it defaults to
1118 "/var/lib/mono/eventlog" on unix and "%APPDATA%no\vent‐
1119 log" on Windows.
1120 win32 Uses the native win32 API to write events and registers
1122 event logs and event sources in the registry. This is
1123 only available on Windows. On Unix, the directory per‐
1124 mission for individual event log and event source direc‐
1125 tories is set to 777 (with +t bit) allowing everyone to
1126 read and write event log entries while only allowing
1127 entries to be deleted by the user(s) that created them.
1128 null Silently discards any events.
1130 The default is "null" on Unix (and versions of Windows before
1132 NT), and "win32" on Windows NT (and higher).
1133 MONO_EXTERNAL_ENCODINGS
1135 If set, contains a colon-separated list of text encodings to try
1136 when turning externally-generated text (e.g. command-line argu‐
1137 ments or filenames) into Unicode. The encoding names come from
1138 the list provided by iconv, and the special case
1139 "default_locale" which refers to the current locale's default
1140 encoding.
1141 When reading externally-generated text strings UTF-8 is tried
1143 first, and then this list is tried in order with the first suc‐
1144 cessful conversion ending the search. When writing external
1145 text (e.g. new filenames or arguments to new processes) the
1146 first item in this list is used, or UTF-8 if the environment
1147 variable is not set.
1148 The problem with using MONO_EXTERNAL_ENCODINGS to process your
1150 files is that it results in a problem: although its possible to
1151 get the right file name it is not necessarily possible to open
1152 the file. In general if you have problems with encodings in
1153 your filenames you should use the "convmv" program.
1154 MONO_GAC_PREFIX
1156 Provides a prefix the runtime uses to look for Global Assembly
1157 Caches. Directories are separated by the platform path separa‐
1158 tor (colons on unix). MONO_GAC_PREFIX should point to the top
1159 directory of a prefixed install. Or to the directory provided in
1160 the gacutil /gacdir command. Example: /home/user‐
1161 name/.mono:/usr/local/mono/
1162 MONO_IOMAP
1164 Enables some filename rewriting support to assist badly-written
1165 applications that hard-code Windows paths. Set to a colon-sepa‐
1166 rated list of "drive" to strip drive letters, or "case" to do
1167 case-insensitive file matching in every directory in a path.
1168 "all" enables all rewriting methods. (Backslashes are always
1169 mapped to slashes if this variable is set to a valid option.)
1170 For example, this would work from the shell:
1171 MONO_IOMAP=drive:case
1173 export MONO_IOMAP
1174 If you are using mod_mono to host your web applications, you can
1176 use the MonoIOMAP directive instead, like this:
1177 MonoIOMAP <appalias> all
1179 See mod_mono(8) for more details.
1181 MONO_MANAGED_WATCHER
1183 If set to "disabled", System.IO.FileSystemWatcher will use a
1184 file watcher implementation which silently ignores all the
1185 watching requests. If set to any other value, Sys‐
1186 tem.IO.FileSystemWatcher will use the default managed implemen‐
1187 tation (slow). If unset, mono will try to use inotify, FAM,
1188 Gamin, kevent under Unix systems and native API calls on Win‐
1189 dows, falling back to the managed implementation on error.
1190 MONO_NO_SMP
1192 If set causes the mono process to be bound to a single proces‐
1193 sor. This may be useful when debugging or working around race
1194 conditions.
1195 MONO_PATH
1197 Provides a search path to the runtime where to look for library
1198 files. This is a tool convenient for debugging applications,
1199 but should not be used by deployed applications as it breaks the
1200 assembly loader in subtle ways. Directories are separated by
1201 the platform path separator (colons on unix). Example:
1202 /home/username/lib:/usr/local/mono/lib Alternative solutions to
1203 MONO_PATH include: installing libraries into the Global Assembly
1204 Cache (see gacutil(1)) or having the dependent libraries side-
1205 by-side with the main executable. For a complete description of
1206 recommended practices for application deployment, see
1207 http://www.mono-project.com/Guidelines:Application_Deployment
1208 MONO_RTC
1210 Experimental RTC support in the statistical profiler: if the
1211 user has the permission, more accurate statistics are gathered.
1212 The MONO_RTC value must be restricted to what the Linux rtc
1213 allows: power of two from 64 to 8192 Hz. To enable higher fre‐
1214 quencies like 4096 Hz, run as root:
1215 echo 4096 > /proc/sys/dev/rtc/max-user-freq
1217 For example:
1219 MONO_RTC=4096 mono --profiler=default:stat program.exe
1221 MONO_NO_TLS
1224 Disable inlining of thread local accesses. Try setting this if
1225 you get a segfault early on in the execution of mono.
1226 MONO_SHARED_DIR
1228 If set its the directory where the ".wapi" handle state is
1229 stored. This is the directory where the Windows I/O Emulation
1230 layer stores its shared state data (files, events, mutexes,
1231 pipes). By default Mono will store the ".wapi" directory in the
1232 users's home directory.
1233 MONO_SHARED_HOSTNAME
1235 Uses the string value of this variable as a replacement for the
1236 host name when creating file names in the ".wapi" directory.
1237 This helps if the host name of your machine is likely to be
1238 changed when a mono application is running or if you have a
1239 .wapi directory shared among several different computers. Mono
1240 typically uses the hostname to create the files that are used to
1241 share state across multiple Mono processes. This is done to
1242 support home directories that might be shared over the network.
1243 MONO_STRICT_IO_EMULATION
1245 If set, extra checks are made during IO operations. Currently,
1246 this includes only advisory locks around file writes.
1247 MONO_DISABLE_SHM
1249 If set, disables the shared memory files used for cross-process
1250 handles: process have only private handles. This means that
1251 process and thread handles are not available to other processes,
1252 and named mutexes, named events and named semaphores are not
1253 visible between processes. This is can also be enabled by
1254 default by passing the "--disable-shared-handles" option to con‐
1255 figure.
1256 MONO_THEME
1258 The name of the theme to be used by Windows.Forms. Available
1259 themes today include "clearlooks", "nice" and "win32". The
1260 default is "win32".
1261 MONO_TLS_SESSION_CACHE_TIMEOUT
1263 The time, in seconds, that the SSL/TLS session cache will keep
1264 it's entry to avoid a new negotiation between the client and a
1265 server. Negotiation are very CPU intensive so an application-
1266 specific custom value may prove useful for small embedded sys‐
1267 tems. The default is 180 seconds.
1268 MONO_THREADS_PER_CPU
1270 The maximum number of threads in the general threadpool will be
1271 20 + (MONO_THREADS_PER_CPU * number of CPUs). The default value
1272 for this variable is 10.
1273 MONO_XMLSERIALIZER_THS
1275 Controls the threshold for the XmlSerializer to produce a custom
1276 serializer for a given class instead of using the Reflection-
1277 based interpreter. The possible values are `no' to disable the
1278 use of a custom serializer or a number to indicate when the
1279 XmlSerializer should start serializing. The default value is
1280 50, which means that the a custom serializer will be produced on
1281 the 50th use.
1282 MONO_XMLSERIALIZER_DEBUG
1284 Set this value to 1 to prevent the serializer from removing the
1285 temporary files that are created for fast serialization; This
1286 might be useful when debugging.
1287 MONO_ASPNET_INHIBIT_SETTINGSMAP
1289 Mono contains a feature which allows modifying settings in the
1290 .config files shipped with Mono by using config section mappers.
1291 The mappers and the mapping rules are defined in the $pre‐
1292 fix/etc/mono/2.0/settings.map file and, optionally, in the set‐
1293 tings.map file found in the top-level directory of your ASP.NET
1294 application. Both files are read by System.Web on application
1295 startup, if they are found at the above locations. If you don't
1296 want the mapping to be performed you can set this variable in
1297 your environment before starting the application and no action
1298 will be taken.
1299 MONO_MESSAGING_PROVIDER
1301 Mono supports a plugin model for its implementation of Sys‐
1302 tem.Messaging making it possible to support a variety of messag‐
1303 ing implementations (e.g. AMQP, ActiveMQ). To specify which
1304 messaging implementation is to be used the evironement variable
1305 needs to be set to the full class name for the provider. E.g.
1306 to use the RabbitMQ based AMQP implementation the variable
1307 should be set to:
1308 Mono.Messaging.RabbitMQ.RabbitMQMessagingProvider,Mono.Messaging.RabbitMQ
1310
1312 MONO_ASPNET_NODELETE
1313 If set to any value, temporary source files generated by ASP.NET
1314 support classes will not be removed. They will be kept in the
1315 user's temporary directory.
1316 MONO_LOG_LEVEL
1318 The logging level, possible values are `error', `critical',
1319 `warning', `message', `info' and `debug'. See the DEBUGGING
1320 section for more details.
1321 MONO_LOG_MASK
1323 Controls the domain of the Mono runtime that logging will apply
1324 to. If set, the log mask is changed to the set value. Possible
1325 values are "asm" (assembly loader), "type", "dll" (native
1326 library loader), "gc" (garbage collector), "cfg" (config file
1327 loader), "aot" (precompiler) and "all". The default value is
1328 "all". Changing the mask value allows you to display only mes‐
1329 sages for a certain component. You can use multiple masks by
1330 comma separating them. For example to see config file messages
1331 and assembly loader messages set you mask to "asm,cfg".
1332 MONO_TRACE
1334 Used for runtime tracing of method calls. The format of the
1335 comma separated trace options is:
1336 [-]M:method name
1338 [-]N:namespace
1339 [-]T:class name
1340 [-]all
1341 [-]program
1342 disabled Trace output off upon start.
1343 You can toggle trace output on/off sending a SIGUSR2 signal to
1345 the program.
1346 MONO_TRACE_LISTENER
1348 If set, enables the System.Diagnostics.DefaultTraceListener,
1349 which will print the output of the System.Diagnostics Trace and
1350 Debug classes. It can be set to a filename, and to Console.Out
1351 or Console.Error to display output to standard output or stan‐
1352 dard error, respectively. If it's set to Console.Out or Con‐
1353 sole.Error you can append an optional prefix that will be used
1354 when writing messages like this: Console.Error:MyProgramName.
1355 See the System.Diagnostics.DefaultTraceListener documentation
1356 for more information.
1357 MONO_XEXCEPTIONS
1359 This throws an exception when a X11 error is encountered; by
1360 default a message is displayed but execution continues
1361 MONO_XSYNC
1363 This is used in the System.Windows.Forms implementation when
1364 running with the X11 backend. This is used to debug problems in
1365 Windows.Forms as it forces all of the commands send to X11
1366 server to be done synchronously. The default mode of operation
1367 is asynchronous which makes it hard to isolate the root of cer‐
1368 tain problems.
1369 MONO_GENERIC_SHARING
1371 This environment variable controls the kind of generic sharing
1372 used. This variable is used by internal JIT developers and
1373 should not be changed in production. Do not use it. The vari‐
1374 able controls which classes will have generic code sharing
1375 enabled. Permissible values are:
1376 all All generated code can be shared.
1378 collections
1380 Only the classes in System.Collections.Generic will have
1381 its code shared (this is the default value).
1382 corlib Only code in corlib will have its code shared.
1384 none No generic code sharing will be performed.
1386 Generic code sharing by default only applies to collections. The Mono
1387 JIT by default turns this on.
1388 MONO_XDEBUG
1390 When the the MONO_XDEBUG env var is set, debugging info for JIT‐
1391 ted code is emitted into a shared library, loadable into gdb.
1392 This enables, for example, to see managed frame names on gdb
1393 backtraces.
1394 MONO_VERBOSE_METHOD
1396 Enables the maximum JIT verbosity for the specified method. This
1397 is very helpfull to diagnose a miscompilation problems of a spe‐
1398 cific method.
1399
1401 If you want to use Valgrind, you will find the file `mono.supp' useful,
1402 it contains the suppressions for the GC which trigger incorrect warn‐
1403 ings. Use it like this:
1404 valgrind --suppressions=mono.supp mono ...
1405
1407 On some platforms, Mono can expose a set of DTrace probes (also known
1408 as user-land statically defined, USDT Probes).
1409 They are defined in the file `mono.d'.
1411 ves-init-begin, ves-init-end
1413 Begin and end of runtime initialization.
1414 method-compile-begin, method-compile-end
1416 Begin and end of method compilation. The probe arguments are
1417 class name, method name and signature, and in case of method-
1418 compile-end success or failure of compilation.
1419 gc-begin, gc-end
1421 Begin and end of Garbage Collection.
1422 To verify the availability of the probes, run:
1424 dtrace -P mono'$target' -l -c mono
1425
1427 On Unix assemblies are loaded from the installation lib directory. If
1428 you set `prefix' to /usr, the assemblies will be located in /usr/lib.
1429 On Windows, the assemblies are loaded from the directory where mono and
1430 mint live.
1431 ~/.mono/aot-cache
1433 The directory for the ahead-of-time compiler demand creation
1434 assemblies are located.
1435 /etc/mono/config, ~/.mono/config
1437 Mono runtime configuration file. See the mono-config(5) manual
1438 page for more information.
1439 ~/.config/.mono/certs, /usr/share/.mono/certs
1441 Contains Mono certificate stores for users / machine. See the
1442 certmgr(1) manual page for more information on managing certifi‐
1443 cate stores and the mozroots(1) page for information on how to
1444 import the Mozilla root certificates into the Mono certificate
1445 store.
1446 ~/.mono/assemblies/ASSEMBLY/ASSEMBLY.config
1448 Files in this directory allow a user to customize the configura‐
1449 tion for a given system assembly, the format is the one
1450 described in the mono-config(5) page.
1451 ~/.config/.mono/keypairs, /usr/share/.mono/keypairs
1453 Contains Mono cryptographic keypairs for users / machine. They
1454 can be accessed by using a CspParameters object with DSACryp‐
1455 toServiceProvider and RSACryptoServiceProvider classes.
1456 ~/.config/.isolatedstorage, ~/.local/share/.isolatedstorage,
1458 /usr/share/.isolatedstorage
1459 Contains Mono isolated storage for non-roaming users, roaming
1460 users and local machine. Isolated storage can be accessed using
1461 the classes from the System.IO.IsolatedStorage namespace.
1462 <assembly>.config
1464 Configuration information for individual assemblies is loaded by
1465 the runtime from side-by-side files with the .config files, see
1466 the http://www.mono-project.com/Config for more information.
1467 Web.config, web.config
1469 ASP.NET applications are configured through these files, the
1470 configuration is done on a per-directory basis. For more infor‐
1471 mation on this subject see the http://www.mono-project.com/Con‐
1472 fig_system.web page.
1473
1475 Mailing lists are listed at the http://www.mono-project.com/Mail‐
1476 ing_Lists
1477
1479 http://www.mono-project.com
1480
1482 certmgr(1), csharp(1), mcs(1), mdb(1), monocov(1), monodis(1), mono-
1483 config(5), mozroots(1), pdb2mdb(1), xsp(1), mod_mono(8).
1484 For more information on AOT: http://www.mono-project.com/AOT
1486 For ASP.NET-related documentation, see the xsp(1) manual page
1488 Mono(Mono 2.5)