Age | Commit message (Collapse) | Author |
|
A temp fix for https://github.com/dotnet/runtime/issues/1933
Co-authored-by: EgorBo <EgorBo@users.noreply.github.com>
|
|
* Remove unnecessary ifdef before undef.
* PR feedback: Remove educational comment.
|
|
Support for Windows Mono NetCore build/test wihtout any need for
cygwin/wsl/automake just MSBuild and MSVC. Windows build support mirror
technologies used by coreclr/aracade builds msbuild + powershell.
Windows only Mono NetCore build, makes a port of existing build.sh and
Makefile, implementing a build.ps1 and build.targets. So far full build
support + execution of corefx test suite is implemented. Other make file
rules can be added when needed.
MSVC build runtime seems to hits a couple of additional test failures
in corefx test suite that needs to be investigated further.
Building NetCore Mono on Windows can now be done without cygwin or wsl.
Build depends on regular VS install (or build tools), if xunit summary
is requested, python needs to be installed.
|
|
They are never checked and all relevant systems have all of them.
|
|
Fix mingw warning unused function __readfsdword.
|
|
Needed in order to setup CI lanes using --enable-cooperative-suspend.
|
|
|
|
Several of the corefx interop sources uses the Unicode names of Win32 symbols.
Our current probing implementation on Windows will test the given name last
when nomangle is not provided (default). On Windows that will be a large number
of probes due to old stdcall name mangling rules. Fix makes sure we first test
the symbol against its charset and the given symbol, before trying the stdcall
name mangling rules. Will reduce the probing a lot on Windows for corefx Win32
interop classes.
|
|
builds.
When running tests on CI the runtime is configured from autogen.sh script.
When running fullaot there are a couple of features not supported so they are
disabled. The problem is that the MSVC Windows builds have its own winconfig.h
template, losing all the disabled features from configures config.h.
This commit adds support to detect the disable defines from configures config.h
if one exists. Since the complexity of this step increases the work previously
done in winsetup.bat has been moved into a msbuild target that is used from
both within VS build as well as winsetup.bat (there are a couple of other builds
using that bat file, so won't remove it).
The winconfig.h template we had is quite outdated compared to what’s generated
by configure. This commit also updates the winconfig.h to closer match what generated
for corresponding mingw build but keep all the Windows specific configurations
included in current version.
|
|
build. LLVM build follows similar pattern as BTLS build and will be build
as part of regular Visual Studio build Mono runtime if LLVM has been enabled
through the autogen.sh, --enable-llvm or –with-llvm argument. It is also
supports msbuild properties MONO_ENABLE_LLVM, MONO_EXTERNAL_LLVM_CONFIG,
if Visual Studio Mono runtime has been built without using autogen.sh.
When just using –enable-llvm, LLVM build will try to build internal LLVM
branch under external/llvm or if override has been set in props file
(using MONO_INTERNAL_LLVM_SOURCE_DIR), an alternative LLVM source
directory path. If –with-llvm has been used pointing to an llvm-config.exe,
no internal LLVM will be build, but the external LLVM build will be used.
Needed LLVM executables (opt.exe, llc.exe) will be installed into regular
Visual Studio Mono runtime build output directory.
The internal Mono LLVM 6.0 release will build as part of changes to this
commit, but it has not yet been fixed to work as expected during runtime.
That work will be done in different commit. The Mono LLVM 3.6 branch will
however work as expected for Windows x64 and can be setup and used using
–with-llvm argument or build as part of Visual Studio build Mono runtime
by enabling msbuild properties, MONO_ENABLE_LLVM and
MONO_INTERNAL_LLVM_SOURCE_DIR.
|
|
(#10996)
initialization, but rather code that is portable to C89 and C++98.
The alternative is also ok, just costs typically a pointer and a relocation per array element,
things most people wouldn't notice but was presumably the point here.
|
|
mono-math.h. (#10830)
MONO_API here was dubious, as all systems have it, except Visual C++ was configured away.
In Visual C++, it is in ucrt, so present in 2015 also.
More information in nearby comments.
|
|
(#10764)
This PR cleanups C++SDKs support and gets them all passing for the first time, esp. Android (WebAssembly already was, iOS uncertain before, green here).
* Current Visual C++ has signbit.
* Rework C++ linkage to C99 math-- trunc, isnan, isinf, etc.
Go through mono wrappers that are compiled as C.
Remove support for Visual C++ pre-2015 and non-C99 Solaris.
(Solaris has plenty of other problems compiling.)
Cleanup Windows ssize_t support.
* Remove trunc and aintl autoconfigury.
Use trunc unconditionally. (aintl is a Solaris near equivalent to trunc).
* Replace dis_isnan with mono_isnan.
* Interpreter already assumes presence of isinf and isfinite, so everywhere else might as well too.
A fair amount of cleanup therefore -- autoconf, ifdef, etc.
If this changes back, the mono_isinf, etc. wrappers are likely, but not necessarily, where to handle it for everyone, not sprinkling ifdefs and alternate implementations around -- assuming all users want the same fallback.
As well, we might want to import some good BSD libc versions of all these if there is any remaining question of portability. *Everyone* except old VAX and Cray have always used the same 32bit float and 64bit double representations since circa 1985 so these are all probably about one line of portable C89/C++98 each, maybe with endian sensitivity.
|
|
|
|
|
|
Enable mono-state-based telemetry for crashing on CI
|
|
* [offsets-tool] Add i386-apple-darwin11.2.0 as an abi target, used only for development.
* [offset-tool] Emit sizes for structures.
* [runtime] Cleanup the cross targets in configure.ac and add more target defines.
Redefine SIZEOF_REGISTER to refer to the target size.
Add TARGET_SIZEOF_VOID_P define and target_mgreg_t type.
* [runtime] Add missing object offsets for x86.
* [runtime] Avoid trying to execute assembly load hooks in aot mode.
* [runtime] Fix the windows build.
* [offset-tool] Fix indentation.
* [runtime] Add a mono_gc_get_target_card_table () function which is the same as mono_gc_get_card_table () but returns information for the target. Use it in the JIT and in places where we generate IL code.
* [aot] Save the card table parameters in the AOT image and check them at load time.
* Fix llvm support.
|
|
This reverts commit f72d9b05296e28ca2a9763d21def7c20e0d97905.
|
|
|
|
* Use __declspec(thread) with Visual C++, and __thread with Win32/gcc,
instead of much slower TlsGetValue / TlsSetValue
* Avoid affecting Boehm.
* Replace HAVE_KW_THREAD and USE_KW_THREAD with MONO_KEYWORD_THREAD.
|
|
Suppress the very many Visual C++-specific warnings introduced recently by typesafe handles.
|
|
Uses mono LLVM master branch, build using cmake and VisualStudio 2015/2017.
Commit adds support for AOT/Full AOT LLVM codegen for Windows x64 Visual Studio
build mono runtime. Normal configure/make using cygwin won’t support LLVM and will
trigger an error if configured.
In order to build using LLVM first mono LLVM master branch must be build using
static linked LLVM configuration (dynamic loading can be added later),
NOTE mono LLVM build needs to include the following commit,
https://github.com/mono/llvm/commit/9b92b4b87607e137266f84dc307181b8842fe54a
in order to successfully build on Windows x64.
Build mono LLVM branch using the following cmake configuration:
-DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ZLIB=OFF
-DLLVM_TARGETS_TO_BUILD="X86"
-DCMAKE_CROSSCOMPILING=False
-DCMAKE_SYSTEM_NAME=Windows
Use cmake with -G "Visual Studio 14 2015 Win64" to generate VS 2015 x64
targets. NOTE, if mono runtime is build using VS 2017, then LLVM should
be build using the same VS version using -G "Visual Studio 15 2017 Win64"
To enable LLVM build in mono.sln, set MONO_ENABLE_LLVM to “true” and make
sure MONO_LLVM_INSTALL_DIR_PREFIX points to the install directory used in
LLVM build above, default msvc/dist/llvm. Above LLVM properties can also
be set if build using msbuild.
A sample LLVM configure script has been included in msvc/llvm-cmake-config.bat.
|
|
(#9115)
|
|
This reduces our dependency on powershell.
|
|
* Fix platform-specific build issues
These changes allow some of the Mono code used by the debugger to build
on a few additional platforms. Specifically, this includes platforms:
* That don't have access to the full Win32 API
* That don't have access to the full Posix API
* That don't support IPv6
* Wrap `access` and `_access` in `g_access`
* Convert indentation to tabs
* Wrap `mktemp` and `_mktemp` in `g_mktemp`
* Wrap `open` and `_open` in `g_open`
* Wrap `write` and `_write` in `g_write`
* Fix indentation
* Use proper asserts
* Add a configure check for `access`
* Remove the use of HAVE_XBOXONE_WINAPI_SUPPORT
* Replace the previous definition of `g_open`
I missed that it was here in my earlier commit, and ended up redefining
it.
* Use `g_error` instead of `g_assert(0)`
|
|
* [metadata] split IL generation code into seperate compilation units.
* [metadata] move ENABLE_ILGEN definition to configure
* [metadata] split IL generation code into seperate compilation units.
By adding callbacks for IL generating runtime code, we can link in code
later into the runtime that does such for configurations which do not
need IL generation initially. This is the case if you configure the
runtime with `--enable-minimal=jit,interpreter`.
In such configuration, the build will produce an additional library,
called `libmono-ilgen`.
An embedded can choose to link this library to the final binary and
initialize IL generation with the following three, newly added, API
calls:
* `void mono_marshal_ilgen_init (void)`
* `void mono_method_builder_ilgen_init (void)`
* `void mono_sgen_mono_ilgen_init (void)`
This change is mostly moving code around, but there are minor changes
like introducing the enum `MarshalTypeCheckPositions`, so we avoid
copy/paste constants accross compilation units.
* [windows] add IL gen files to windows build and set ENABLE_ILGEN
* [fixup!] fix windows build
* [fixup!] resolve merge conflicts with class getter commits
* marshal.c: b8da9736209427ef49267923e1321c801c65dfd2
* sgen-mono.c: 8ba4947f7a3b37b3c5e5458834109fad317f91bc
at some point I gave up to resolve merge conflicts and worked through
errors/warnings by compiling with
> `CFLAGS=-DENABLE_CHECKED_BUILD_PRIVATE_TYPES=1`
so the result is likely a bit different
* redo lost changes from 57f3f34e60ee6d17fb1dada4b8799f3d753ca2b0
* redo lost changes from 52514effbf19992edc323ff9d7bf21766bc50b2c
* [fixup!] fix array marshal
* [method-builder] use eglib types
review comment by Ludovic,
https://github.com/mono/mono/pull/7375#discussion_r171876337
* [marshal] remove stelem strings from header
review comment by Rodrigo,
https://github.com/mono/mono/pull/7375#discussion_r171921029
|
|
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.
|
|
* [interp] enable it by default in configure
can be disabled via --enable-minimal=interpreter, like other components in the
runtime.
* [interp] use DISABLE_INTERPRETER in Makefile.am.in so it is closer to what we had before
* [interp] improve handling of interpreter flag and also check if we are on a cross-compile runtime
* [configure] add interpreter to the list of --enable-minimal
* [ci] remove --enable-interpreter from script
* [windows] disable interpreter for now
* [driver] add output about availabilty of interpreter in --version
* [man] add entry to mono.1 about --interpreter
* [driver] update --interpreter handling
|
|
|
|
similar to utils/ etc. (#5297)
|
|
This reverts commit 501e77f91215d31c56aa63de0c99c91d8b13bfa5.
superseded by https://github.com/mono/mono/pull/5000
|
|
|
|
This enables IPv6 support on Windows.
|
|
This makes it possible to version the runtime<->corlib interface
for each version branch independently and fixes the problem
of monolite getting overwritten by changes in different branches
when corlib version is still the same.
We're moving definition of the corlib version into configure.ac
so we can more easily bake the Mono version into it.
|
|
This commit improves the unwind support on Windows x64 by implementing a number
of missing features. It also adds support for out of proc function table callback
module on older OS versions and switch to different function table methods
(growable function tables) on Win8/Win2012Server and later OS versions.
Commit aligns more to the windows x64 prolog/epilog ABI, but since mono
uses negative offsets from frame pointer while x64 windows uses positive, it is
not possible to do a 100% "correct" representation in the prolog, but if we don’t
give the OS unwinder the full unwind metadata in the frame pointer use case,
we can trick unwinder to do the right thing presenting correct callstacks in
debuggers.
Commit includes representation of windows unwind info in mono's unwind data
using extensions to better integrate windows specific unwind info in
areas currently not supported (like trampolines). It will also be easier to implement
unwind info in full AOT objects in the future, if windows specific unwind data is
included in mono’s unwind data structures.
On Win8/Win2012Server and later OS versions, all function table data is registered
using growable function tables giving full support for callstacks on live debug targets
and crash dumps. On previous OS versions function table callbacks are used together
with an out of proc module. This works for live debugging in WinDBG and Visual Studio
(if right permissions are given to the debuggers to load out of proc unwind module).
Crash dumps works as expected in WinDBG but currently not in Visual Studio for older OS
versions using callback support. If that use case needs to be supported it needs to be
solved in a separate PR, but since we support crash dumps in Visual Studio on later OS
versions and in WinDBG on earlier, it is still possible to analyze crash dumps by picking
the right tool.
Debuggers needs some additional information to work with function table callbacks out of proc
modules (NOTE, this is NOT needed on Win8/Win2012Server and later).
WinDBG:
To just do live debugging, it is possible to run the following command in WinDBG,
settings set EngineInitialization.VerifyFunctionTableCallbacks=false
To do crash dump analysis the following registry key needs to be set,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\KnownFunctionTableDlls
Add the full path to mono-2.0-dac-sgen.dll matching the mono-2.0-sgen.dll as a 32-bit REG_DWORD.
NOTE, adding the registry key removes the need to set the setting.
Visual Studio:
To do live debugging, set the same registry key as WinDBG use case.
|
|
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 eglib under none desktop Windows API family. Classic
Windows API have been split into families and partitions in order to support
different subsets on different Windows platforms. In order to build against
other Windows targets/platforms Mono needs to follow these families/partitions
in order to successfully build where API’s have been removed/replaced. Since most
Mono platforms uses the Windows API signatures a new defined has been added to all
platforms, HAVE_CLASSIC_WINAPI_SUPPORT, used to decide what implementation to include.
On none Windows platforms this is always defined and on Windows platforms it follows the
winapifamily.h. In order to keep down regressions, the existing API’s are kept for HAVE_CLASSIC_WINAPI_SUPPORT
even if there are more modern replacements available.
|
|
|
|
got mixedup.
Caused incorrect exception behavior and failures in basic.exe, exceptions.exe regression test on x64 windows. This was due to the fact that some source files didn't include signal.h while others did. In case where signal.h was not included incompatible defines were used for SIGILL and SIGFPE in mini-amd64.h.
|
|
|
|
A small powershell command grabs the version number from configure.ac and uses it during winsetup.bat,
this way we don't have to manually keep them in sync.
|
|
They were missed in 43403b8221ed0d6e65d4766fc629f178915df4e4.
|
|
|
|
|
|
|
|
|
|
|
|
This has not been supported for a while, so remove it.
|
|
|
|
|