| Age | Commit message (Collapse) | Author |
|---|
|
|
|
make update-solution-files works but actually throws an ArgumentOutOfRangeException and as a result - corrupted csproj (fails on System.Runtime.CompilerServices.Unsafe -
System.Runtime.CompilerServices.Unsafe.dll.sources is empty)
|
|
|
|
|
|
it was fine on CI, but developers can run into build errors if they
don't follow a strict order (due to autotools fighting with
`winconfig.h`).
`basic.exe` passes, but everything involving native transitions crashes.
|
|
|
|
|
|
push/mark roots.
|
|
|
|
* Exclude a couple of sources currently not building anything useful on Windows.
* Added MONO_EMTPY_SOURCE_FILE to a couple of source files ending up empty by default.
* Excluded API's not included on UWP targets.
* Explicitly declared import project paths in target files.
* Added support to define x64 MASM build outside default targets file.
|
|
mono_atomic_<op>_<type>, with a consistent signature on all platforms, including Windows implementation. (#5767)
* [runtime] Rename atomic functions from the win32 style naming to mono_atomic_<op>_<type>, with a consistent signature on all platforms. This fixes a large number of warnings on windows.
* Add Windows implementaiton of mono_atomic_*.
* Windows implementation of mono_atomic_* inline functions.
* Changed naming typo in mono_atomic_xchg_i32Add and mono_atomic_xchg_i32Add64.
* Fixed some additional signed/unsigned/volatile warnings when using mono_atomic_*
* Fixed some smaller additionl warnings.
* Fix Interlocked* to mono_atomic_* name change in signal.c
* Additional name adjustment of atomics.
Aligning more towards C11/C++11 standard namings:
mono_atomic_xchg_add_i32|i64 -> mono_atomic_fetch_add_i32|i64
Changed from mono_atomic_add to mono_atomic_fetch_add in cases when return
type is not used.
Also includes small mingw build fix on Windows.
* Aligned loads with C++11 implementation using explicit compiler barrier.
On x86/x64 Windows, reading a properly aligned 8,16,32 bit volatile variable
(using /volatile:ms extension) should have acquire semantics. On x64
this also includes 64-bit properly aligned volatile variables.
The C++11 implementation does however include an explicit _ReadWriteBarrier in
its sequentially consistent implementation to instruct compiler to not reorder
load/stores. Since compiler supports two modes of volatile behavior (ms/iso)
this additional barrier is probably there for consistency, independent of the
behavior of volatile keyword.
NOTE, the x86/x64 CPU architecture has strong guarantees regarding load/store of
memory operations, so issuing a CPU memory barrier for loads should not be needed
(and is not done in C++11 atomics implementation).
This commit also adds a couple of optimizations for 32-bit loads and for x64,
64-bits loads. The C++11 implementation uses the same pattern loading them as 8
and 16 bits variables, so no need for Interlocked* calls to load 32-bit and for x64
64-bit variables.
|
|
When I simplified MONO_CORLIB_VERSION to only include major.minor
instead of major.minor.build in https://github.com/mono/mono/pull/5449
I forgot to apply the same change to the msvc copy of that logic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
library support.
|
|
Make libmono-static lib file include all needed runtime libs making it easier to
link and distribute as part of Mono SDK.
Commit also updates linking of vcxprojs in mono.sln to use merged static lib.
|
|
(#5517)
* [trace] remove code that has no effect
* [trace] move program assembly out of MonoTraceSpec
The assembly member represents the program assembly. It's
information the trace spec is matched against, not part of
the trace spec per-se (if two trace specs exist for two purposes
we would still have one program assembly)
* [trace] remove side effects from get_string()
On the way towards supporting multiple trace specs,
remove side effects from get_string() function.
* [trace] remove side effects from get_token()
Remove side effects from get_token() to allow handling
multiple trace specs.
* [trace] fix handling of double exclusion and disabled
When encountering "disabled", do not add an entry to
the trace spec
Fix error handling around double "-" - get_spec()
never returns TOKEN_EXCLUDE and the recursion can
be easily avoided.
* [trace] remove side effects from get_spec()
Another step in making the trace options reusable.
* [trace] rename mono_trace_parse_options() to mono_trace_set_options()
This routine actually sets the tracing options, not just parses an
option string, so set_ is more suitable. This frees up the
mono_trace_parse_options() name for pure parsing, when we later
reuse the parsing code.
* [trace] make tracing options API reusable
Add APIs that parse tracing options and evaluate a method
against the parsed options. The tracing functionality now uses
this API, but other components can use this to apply an operation
to a method based on policy (e.g. profiling)
* [trace] rename MonoTraceSpec to MonoCallSpec
In preparation for reusing call specification beyond the
tracer, rename the data structure - it now only specifies
a set of calls, without indication what should be done with
them.
* [trace] rename mono_trace_set_assembly to mono_callspec_set_assembly
As it becoming a reuse candidate, we remove the "trace" component
from the name.
* [trace-metadata] move callspec code into its own module
Introduce callspec.c/h which encapsulate the call specification
functionality.
* [profiler] add "callspec" option to log profiler
The callspec option define which methods get instrumented
at JIT time with entry/exit calls to the profiler. The
syntax is same as the tracer (--trace=) syntax. To
distinguish between profiler options and callspec, wrap the
callspec with double quotes, as in:
--profile=log:callspec="all-mscorlib",calls
Since this typically runs from a shell, the double quotes have to be
escaped or wrapped in single quotes, as in:
mono '--profile=log:callspec="all-mscorlib",calls' prog.exe
* [metadata] add an error return string to callspec parsing
Instead of printing parsing error messages to standard error,
return an error string. That allows the client to do the right thing
with the error.
|
|
lateralusX/lateralusX/windows-mono-debugger-soft-hang
Fix sporadic hang in Mono.Debugger.Soft test suite on Windows.
|
|
* add tests to net_4_x.sln
* remove redundant string.Format
|
|
Mono.Debugger.Soft has low frequency hangs in InspectThreadSuspenedOnWaitOne test.
This method launch the debuggee (dtest-app.exe), sets a breakpoint on a method just
doing an infinite OS wait, validate that the breakpoint gets hit and resumes debuggee.
After resume from breakpoint debuggee will hit the infinite OS wait and the debugger test
will suspend and shutdown the process.
In order for mono debugger to handle the shutdown request it will suspend all managed threads
using mono_thread_suspend_all_other_threads. This method uses a pooling schema until all threads
have reported that they are suspended. Since one of the threads are doing an infinite OS wait we
entered the land of APC (Asynchron Procedure Calls) used on Windows to alert waitable threads.
The reason for the hang is the fact that the OS won’t return from the wait until all queued APC’s
have been executed. Since the loop sending async suspend requests to the
threads mono_thread_suspend_all_other_threads can run faster (including suspending/resuming the
thread that need to consume APC’s in the process) then the dequeue and execute of the queued APC’s, the
wait won’t break, meaning that the thread won’t be able to set the mono suspend state causing the
mono_thread_suspend_all_other_threads to run forever. This is highly timing dependent and will only reproduce
sporadic, but I was able to isolate and do a solid repro locally while working on the fix.
The fix makes sure we don’t post a new suspend APC if there is already one in flight with a pending unhandled
interruption. This will make sure we won’t flood the APC queue on Windows preventing the thread from suspending.
|
|
|
|
* Introduce racing.h
- introduce the `RacingIncrement* ()` functions
- test the `RacingIncrement* ()` functions with races of `mono_stats` in class.c
- add racing.h to Makefile.am, libmonoutils.vcxproj and msvc/libmonoutils.vcxproj.filters
* [fixup!] Rename "racing" to "unlocked"
- rename racing.h to unlocked.h
- update new file name in Makefile.am and *.vcxproj* files
- rename the functions from Racing* to Unlocked*
- update the macro logic
|
|
similar to utils/ etc. (#5297)
|
|
It doesn't need to be in a separate PropertyGroup.
|
|
|
|
These symbols weren't being properly exported in the final mono executable on
Mac because no code in the runtime called these functions. As long as they're
defined in an object file that contains used functions, they'll be exported.
|
|
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.
|
|
|
|
|
|
So mono_profiler_init becomes e.g. mono_profiler_init_log.
This allows us to link together multiple profilers into a single module and
load them selectively. This is especially useful for XA/XI/XM.
|
|
[profiler] Housecleaning
|
|
ValueAdd was added over a decade ago and all the tests marked with this category are passing now.
We have *tons* of tests that rely on working DNS/Internet that aren't marked with
InetAccess (and they actually provide good value so we don't want to exclude them).
Since these categories don't really make sense and just causes confusion
it's better to just remove them.
|
|
|
|
Location of ml.exe and ml64.exe is different in VS2017 compared to VS2015.
By removing the partial path from the command, the VS environment will locate
the tool depending on selected build configuration and VS version.
This should work for both VS2015 and VS2017.
|
|
|
|
available. (#5147)
|
|
https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html
|
