| Age | Commit message (Collapse) | Author |
|---|
|
They can be used with native line endings.
We now have a shared folder with the dotnet repos and they have CRLF normalization enabled.
This difference leads to conflicts while applying changes from the dotnet repos to mono.
|
|
library support.
|
|
When this feature is enabled for a method, the enter/leave event receives an
additional argument, a so-called 'call context'. This call context contains
enough information about the stack frame of the instrumented method to allow
the enter/leave callback to inspect the 'this' reference, method arguments,
local variables, and the return value (for non-void methods).
This feature enables some interesting scenarios that were not possible with
the regular enter/leave events. For example, a profiler could instrument
well-known methods in the managed thread pool code to get an idea of how an
application is using the thread pool, or it could instrument network-related
methods to gather statistics or even log all network traffic.
This is implemented by storing a MonoProfilerCallContext on the stack, whose
MonoContext field is populated by executing an OP_FILL_PROF_CALL_CTX opcode
which stores the stack pointer, frame pointer, and all callee-saved registers
to it. For the epilogue, a pointer to the return value (for non-void methods)
is also stored in the MonoProfilerCallContext. An address to this context is
then passed to mono_profiler_raise_method_enter/leave. Based on debug info,
all arguments and locals can then be looked up in the instrumented method's
stack frame.
For the interpreter, we just store an InterpFrame pointer on the
MonoProfilerCallContext and look everything up from that. We don't need debug
info in this case.
This feature is currently not supported with LLVM (for regular LLVM mode, it
will fall back to Mono's JIT, while for LLVM-only mode, it's not available).
I also refactored the interpreter code so that enter/leave events are generated
not only when interpreter debugging is enabled. Also, the interpreter will only
call mono_profiler_get_call_instrumentation_flags () once per method now.
Finally, I made the interpreter also generate exception leave events.
|
|
* [interpreter] Add beginnings of debugger support.
Handle debugger support similarly to the JIT:
- Add a MINT_SDB_SEQ_POINT instruction to the debugger IR. Replace it with a MINT_BREAKPOINT instruction when a breakpoint is placed.
- Store the sequence point information in the existing sequence point data structures.
* [interp] Add support for debugger stacktraces.
* [interp] Add support for debugger frame info.
* [interp] Connect seq points inside the same basic block so simple single stepping works.
* [interp] Link sequence points in different basic blocks the same way the JIT does it.
* [interp] Allocate some bitsets from a mempool.
* [interp] Rewrite the patching in the transform pass to make it a bit easier to understand.
* [interp] Add interruption support for sdb.
* [interp] Add support for mkrefany,refanytype and refanyval.
* [interp] Fix debugger failures.
* Add support for setting byref variables.
* Fix thread interruption when the top frame is an interpreter frame.
* Allow stack walks when a thread is suspended while transforming a method.
* Implement method entry/exit events.
* Fix ldstr+dynamic methods.
* [interp] Implement support for Debugger.Break.
* [interp] Change the offsets in MonoJitInfo/seq points into byte based from short based to reduce the amount of special casing needed in other parts of the code.
* [interp] Factor out the push/pop lmf code into a pair of helper functions.
* [mixed] Fix mixed mode EH.
* [interp] Implement support for MONO_VERBOSE_METHOD. Improve sequence point placement.
* [interp] Implement support for SetIP ().
Pass the target thread as an additional argument to mono_interp_set_resume_state (). Check the resume state after single
stepping/breakpoints in the interpreter.
* [interp] Disable the usage of the STLOC_NP opcodes when running under the debugger, it doesn't work if the ip is changed when the execution is stopped.
* [interp] Fix async stack walks in the debugger when the thread is in native code called from interpreter code.
* [interp] Fix the disable interpreter build.
* [interp] Fix the calculation of native offsets in the line number info.
* [interp] Fix the build.
* [interp] Make CMD_STACK_FRAME_GET_THIS behave the same when called on managed-to-native frames, with the interpreter, frame->has_ctx is set.
* [interp] Fix typos, remove some dead code, use g_print instead of printf in a few places, move some interpreter stubs to interp-stubs.c.
|
|
|
|
|
|
|
|
|
|
cleanup.
Continuation work on previous none desktop Windows API family PR's adjusting all
changes to similar patterns used over previous PR's. This PR also move the logic
to silence a MS VS linker warning on empty source files into a macro. It also includes
the use of the macro in a couple of more source files causing linker warnings when build
on none desktop API families excluding JIT support.
Since other Windows API family work is still in progress it also disables build capabilities
for none desktop API families.
|
|
Initial work to build libmono under none desktop Windows API families.
|
|
additional test/debug projects. (#3420)
* Fixing linker warning when building libmono DLL.
After splitting mono runtime into a static library used when building libmono
DLL, we got a linker warning since there were no object files left in the
libmono project. There was also a sematic issue with the current organization
of DllMain since it is located in driver.c that will be compiled into the static
library and then consumed by the linker building the DLL. In cases where the
static library was consumed directly it would still include DllMain entry point.
By splitting the DllMain method implementation into a separate specific windows file
we can both resolve the linker warning and remove the DllMain method implementation from the static
library and only include it when building the libmono DLL.
* Visual Studio projects support to optimally link mono applications using static libmono library.
Added a new property, MONO_USE_STATIC_LIBMONO that can be used to link some
mono applications, for example mono(-sgen).exe, towards static version of libmono.
This gives us the option to build a binary without dependencies on other runtime binaries
minimizing what’s needs to be deployed in order to run mono. This in combination with static linked c-runtime
(another option available through a VS property) will produce a mono runtime binary without
addition dependencies except .NET assemblies deployed by mono runtime users.
The default is still using the dynamic version of libmono as before.
* Visual Studio project to test/debug testdriver tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run testdriver related tests
directly from within Visual Studio.
Commit also includes an additional configuration script that can be used test projects in order
to setup a mono config file. The testdriver project uses this to create a unique configuration
files pointing to the build libtest.dll for running configuration. The configuration file will then
be used when the tests are executed to make sure the correct libtest.dll for current build configuration
gets used when running test different tests from within the Visual Studio debugger.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-testdriver-test property sheet added to the project:
MONO_TESTDRIVER_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
* Visual Studio project to test/debug nunit tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run nunit related tests
directly from within Visual Studio.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-nunit-test property sheet added to the project:
MONO_NUNIT_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
There is also an additional user macro defined:
MONO_NUNIT_FIXTURE
This can be used to limit the number of nunit test run within a test suite.
|
|
libmono will use static library when building its dynamic library. This gives
the option to build binaries that could link the static version of mono runtime
or use the dynamic version of the same library. The default build binaries still
link against the dynamic version of the runtime.
|
