| Age | Commit message (Collapse) | Author |
|---|
|
Changes will default Windows SDK version as well as Platform Toolset to
the default versions used in the targeted VS version. If the projects are
opened up in VS2015, it should default to Windows SDK 8.1 and v140, but if
the same projects are opened in VS2019, it will default to latest Windows SDK 10
and v142. This way the project files should adapt to used VS version, meaning
that we could still build them using VS2015 (what's currently used on CI) but also
using VS2017 and VS2019. There should not be a need to install any previous versions
of build tools, unless an older version is targeted. It is also possible to set
PlatformToolset when calling msbuild and that should adapt to corresponding default
Windows SDK version for targeted toolset version.
Commit makes many changes and adjustments, aligning all vcxproj files but changes
should not affect build output.
|
|
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.
|
|
By default, all projects are build using "default" compiler based on source
file extension. There is a property in mono.props, MONO_COMPILE_AS_CPP
that could change this and build selected projects (eglib, libgcmonosgen,
libmini, libmono-dynamic, libmono-static, libmonodac, libmonoruntime,
libmonoutils, mono, monodis, monograph and pedump) using C++ compiler.
MONO_COMPILE_AS_CPP property could be set when calling msbuild
or through VS property manager IDE. Default value is false building using
"default" compiler (current behavior). When setting MONO_COMPILE_AS_CPP=true
the build prefix will be altered to make sure the C++ build gets its own build
folder, parallel to default build folders.
Example of building using C++ compiler from msbuild:
msbuild /p:PlatformToolset=v140 /p:Platform=x64 /p:Configuration=Release /p:MONO_TARGET_GC=sgen /p:MONO_COMPILE_AS_CPP=true msvc/mono.sln
|
|
library support.
|
|
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
|
|
available. (#5147)
|
|
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.
|
|
* [suspend] Remove sgen specific suspend code
* [sgen] Remove unused SgenClientThreadInfo->stopped_domain field
* [sgen] Remove unused SgenClientThreadInfo->stopped_ip field
* [threads] Unsplit code for syscall abort
* [threads] Reuse posix suspend signal handler function for abort
* [mono-threads] Move debug printf to separate file
This is to avoid recompiling half of the runtime for every change to these printf.
* [stw] Slightly improve logging
* [mono-threads] Fix unified thread suspend
`mono_threads_suspend_begin_async_suspend` return FALSE iff it coudn't successfully suspend the thread, not if the thread is not in the correct state. The latter is checked by calling `mono_threads_suspend_check_suspend_result` which will return FALSE if we couldn't initialize the state of the suspended thread.
* [mono-threads] Fix unified thread suspend
If we try to suspend a thread that is still attaching, we might suspend it after it allocated the MonoInternalThread and MonoThread, but before it set the current domain or lmf. This would lead us to not scan the thread stack, which would lead to collect the newly allocate MonoInternalThread/MonoThread, leading to a crash. By letting sgen deal with the thread, even if the domain or the lmf is not set, we avoid this bug.
This makes unified suspend have the same behaviour as the previous sgen specific suspend.
* [mono-threads] Fix compilation
|
|
This was introduced in 92be5357d12ecf0cc4c51fbcb76fc0514b375d1c. The patch
also adds the os-event-win32.c file to the libmonoutils Visual Studio project.
|
|
Initial work to build libmonoutils under none desktop Windows API families.
|
|
* Revert "Revert "Enhance log tracing""
This reverts commit 565c6ac0802eedf68755bd5776c80b00ab388415.
* Better handle legacy log handler processing with suggestions from lamdageek
* Remove unnecessary assignment
* Restore mono_trace_set_log_handler parameters to their original specification
|
|
naming for intermediate pdb files for exe/dll's.
All artifacts will now have the same name of their final pdb file as
the library/dll/exe target file name.
The problem with the naming turns out to be a problem in Visual Studio
when a exe/dll use the same name of its intermediate pdb files and final
pdb file. In that case the final pdb file produced by the linker will be
incorrect and not usable by the debugger. This was the reason for the initial
change, giving intermediate pdb files a different name. Moving back to the
default naming for intermediate pdb files for exe/dll's will give the same
effect (a different name) and since libraries are not affected by this
problem, libraries can use the target name for their pdb files as well.
|
|
on platform.
|
|
* Updated vs project files to resolve winsock, winsock2 build dependecies.
* Added vs project running basic mono-mini regression tests.
|
|
naming conflicts when linking.
|
|
* Enabled build target suffix in order to lable a build (primarly for sgen).
* Enabled separate build tree.
* Dropped all sgen configurations, replaced by properties and target suffix.
* Fixed pdb naming of intermediate pdb files.
|
|
|
|
* Upgraded all projects to new vs2015 tool chain.
* Used mono.props through property manager instead of import.
* Fixed dependencies to be more explicitly in additional dependecies.
* Fixed error in mono.props, switched $ to % when referencing internal variables.
* Added property variables for includes and libraries, defined in mono.props.
|
|
|
|
|
|
|
|
abort time
libmonoutils.vcxproj - Add new logging source code files to the project
|
|
a595d489fa64d8e213c74470f23c576296e2d548
The .vcproj's and .def's weren't updated and there was a typo in mono-os-mutex.h that caused a build break.
|
|
|
|
This reverts commit 64af68dd8d7ba888ad9e5d35dc9714df6f9d5963.
|
|
|
|
Previous patch missed some build files.
|
|
In some more esoteric environments (say bash.exe spawned by
jenkins-slave.exe), the _MASM target's attempts to call ml.exe fail
due to ml.exe missing from $PATH (even when it appears to be fine).
The ClCompile target doesn't suffer this issue, since it uses the
full path to CL.exe rather than assuming CL.exe is in $PATH.
Bundle a lightly patched masm.props to duplicate the ClCompile
target behaviour.
This should have no impact on you unless for some reason you're
using a different MASM to the one provided with MSVC.
|
|
|
|
|
|
|
|
|
|
This reverts commit 577482e3361159e0c4c4b0232a07195ba91335dd.
We dropped XP support (see https://github.com/mono/mono/pull/1723),
so this is no longer necessary.
|
|
They're basically the same thing, but v120 has DX10+ capabilities and v120_xp
is DX9 only. Since we're not building against DirectX, the difference is
purely academic - but changing the value to v120_xp means MSVC binaries run
on XP+, not Vista+
|
|
Even though this seems like it's just moving the files around in the project, for some reason it makes a difference to VS.
|
|
|
|
This reverts commit 25969466b5339ed263eaca87d5181ce5c4ef9baa.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
that code into a .asm file.
|
|
some new sgen files.
|
|
|
|
|
