| Age | Commit message (Collapse) | Author |
|---|
|
* [build] Unify bootstrap profiles
We can now rely on build only as we have reliable monolite and package
compilers
* Fixes genproj dependencies
* [csproj] Update project files
|
|
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.
|
|
mono_domain_try_type_resolve_typebuilder, mono_domain_try_type_resolve, mono_domain_try_type_resolve_name. (#10675)
* Convert or partially convert mono_domain_try_type_resolve_typebuilder, mono_domain_try_type_resolve, mono_domain_try_type_resolve_name.
In order to use TYPED_HANDLE_DECL, this required splitting handle.h into at least two pieces,
here called handle-decl.h and handle.h.
A fair amount of early returns had to be converted.
* PR: Move mono_domain_try_type_resolve_name from domain-internals.h to reflection-internals.h.
Move mono_domain_try_type_resolve_typebuilder ditto.
Move ves_icall_TypeBuilder_create_runtime_class from object-internals.h to reflection-internals.h.
Move TYPED_HANDLE_DECL (MonoReflectionAssembly) from handle-0.h to reflection-internals.h (previously object-internals.h)
Move TYPED_HANDLE_DECL (MonoReflectionTypeBuilder) ditto.
Add MONO_HANDLE_BOOL to handle.h so we can 1. Stop inverting tests and 2. Prefer
true first in ternary.
x = MONO_HANDLE_BOOL (y) ? z : 0
instead of
x = MONO_HANDLE_IS_NULL (y) ? 0 : z
Add include "reflection-internals.h" to mono-security.c
Add include "reflection-internals.h" to security.h
object-forward.h:
Place MONO_RT_MANAGED_ATTR on MonoReflectionTypeBuilder.
Really it should just be MonoObject, and then implied
by everything that contains it.
Place MONO_RT_MANAGED_ATTR consistently.
Sort by native then managed.
mono_reflection_get_type_with_rootimage: Rename assembly to refection_assembly
and then use assembly to reduce occurences of MONO_HANDLE_GETVAL (assembly, assembly).
mono-security.c: include config.h unconditionally and just once.
* Change mono_class_get_ref_info_raw to return MonoReflectionTypeBuilder* instead of MonoObject*.
Remove casts on mono_class_get_ref_info_raw calls.
Change mono_class_get_ref_info to return MonoReflectionTypeBuilderHandle instead of MonoObjectHandle.
Move mono_class_get_ref_info from object-internals.h to reflection-internals.h.
Use mono_class_get_ref_info instead of mono_class_get_ref_info_raw.
* Cleanup -- MONO_HANDLE_BOOL and contains instead of cast.
* PR: Fix incorrect comment. Fix precise GC hole wrt invoke.
|
|
jay) (#10485)
* Fix forceBuild not working for projects with unknown platform names (i.e. jay)
* Clean up error messages
|
|
|
|
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
|
|
override it (#10429)
* Move the PreBuild dependency property later in the file so targets can't override it
* [csproj] Update project files
|
|
cil-stringreplacer (#10381)
This ensures that System.CompilerServices.Unsafe has implemented method bodies, necessary for Span and similar use cases.
|
|
* Remove use of sln dependencies and use csproj project references instead
* Rewrite jay.vcxproj so it builds correctly even without help from the sln file
* Force pre-build event to run after references are resolved. Change how culevel.exe path is computed to be more resilient.
* [csproj] Update project files
|
|
https://github.com/mono/mono/pull/10252. (#10377)
|
|
* [cxx] int vs. enum.
There are at least three or so approaches to this.
1. Sprinkle around casts.
2. Overload operators.
2a. Bit-only (| & ^ |= &= ^=) This PR.
2b. Also math (+ - ++ -- == !=)
3. typedef to int instead (https://github.com/mono/mono/pull/10231)
They all have tradeoffs.
1. Casts: The most line damage. Not huge, but the most.
2. Overloads: New idiom to some but an old idiom. Supported in this way by windows.h even.
This is the most "C++y solution".
3. int: Highest level of source compat and semantic compat. Least line damage (just
change the declarations). Least debuggable and least typesafe.
In terms of semantic compat, even in C the guarantees aren't particularly strong.
Some enums will be int, some unsigned, depending on the values and the compiler.
Perhaps even other types, but I doubt it.
I observe C++ compilers don't tend toward unsigned the same way, so switching
to C++ will on some platforms lose unsignedness. Given we didn't have it portably
anyway, should be ok.
A typesafe enum has the properties that enum A cannot be silently assigned to enum B (ok,
there might be a warning), or from an integer.
A typesafe enum, bitfield or otherwise, can/will be shown symbolically by a debugger.
(lldb does not handle bitfields, only strict enums)
A C enum might be debuggable, w/o typesafety.
A C enum can be freely mixed with other enums and integers.
A C++ enum is more restricted.
Using typedef int, is a maybe surprising option, but does provide the closest meaning to C enum.
Per guidance, this PR also changes one enum to #defines + int.
* PR: "mono" => "g"
"T" => "type"
static_cast where it works (not to reference)
Use templatized typedef instead of macro, if it works on g++4.4.
Add test.
Provide to build eglib tests.
Borrow CXXFLAGS_COMMON from https://github.com/mono/mono/pull/10271.
Add some const to test harness.
* g++4.4 compat (not quite C++11) -- use macro, not template typedef.
* Fix real problem with aliasing seen with g++4.4.
Use attribute(may_alias) when casting pointers/references.
* Add mono/eglib/test/enum.cpp.
|
|
It was removed in c16ff9ab235abef10213f49dceb5251c7d8f6efd.
|
|
|
|
for sources in projects so that we don't get erroneous duplicate files in cases where there are both profile and host platform criteria (#9952)
A recent commit revealed that in cases where we select based on a mix of host platform and profile, genproj csproj files can end up with duplicate sources because the existing <ItemGroup Condition= approach could make multiple groups match for a given compile when we really just want one.
This PR changes to generating a cascade of msbuild <Choose> elements, which give if-else selection to ensure that we only ever build a single set of files.
|
|
building using msbuild (#9859)
* Manually add a csproj file for cil-stringreplacer
Adjust trace level for genproj
* Manually add cil-stringreplacer to bcl.sln and set it as a dependency of corlib
* Fix typo
* Add post-build event to corlib that runs cil-stringreplacer on it in mscorlib mode
* [csproj] Update project files
|
|
of solution dependencies (#9670)
Using solution dependencies in ```bcl.sln``` seems flaky and seems like it might not establish the full ordering we need to ensure that ```Consts.cs``` exists before we build things that require it. Let's try using project references (where ```corlib.dll``` 'depends' on ```genconsts.exe```) instead. This should also insert the dependency for any project that includes Consts.cs instead of just corlib.
This PR also makes update-solution-files actually fail if ```genconsts.exe``` fails to build because it was driving me mad.
Part of #6886
|
|
hash or github PR). (#9787)
|
|
|
|
|
|
The Microsoft.CSharp.targets import needs to come before the PostBuildEvent,
otherwise TargetPath won't be set.
|
|
This adds a simple script for generating Consts.cs that can run on Windows, and makes it a dependency of corlib.csproj in the BCL solution file. From my initial testing this will autogenerate Consts.cs if it's missing and then corlib will successfully build.
This (mostly?) addresses issue https://github.com/mono/mono/issues/6886.
This currently has an awkward dependency on ```winsetup.bat``` and I modified it slightly to make it clearer whether the batch file succeeded.
|
|
Enable SIMD optimization on Windows x64.
|
|
When implementing Windows x64 valuetype ABI mono’s SIMD optimization didn’t
handle the case when passed arguments uses ArgValuetypeAddrInIReg/
ArgValuetypeAddrOnStack so optimization was disabled on Windows x64.
This commit fixes mono SIMD support for ABI’s passing value types using
ArgValuetypeAddrInIReg/ArgValuetypeAddrOnStack on Windows x64. It does this
as part of regular value type decomposition, including a pass decomposing SIMD
intrinsic ending up as arguments of type OP_ARG into correct load/store of the
value type reference before argument can be used by SIMD instructions.
All JIT and full AOT regression tests pass with enabled SIMD optimization
on Windows x64. Running this optimization on some vector intensive applications
showed some great performance increase. Just running this on basic-simd.exe
regression shows:
Elapsed time: 0.040471 secs (no optimizations at all)
Elapsed time: 0.015756 secs (only simd and intrins optimization)
So in this small, isolated test, the optimization indicates a 2.5x performance increase.
|
|
|
|
host platform (#8985)
* Update genproj makefile to include gensources
Update genproj argument parser to be more generous about displaying help
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Fix rebase issue
* Checkpoint
* Checkpoint
* Fix built sources only being added to one profile
* Fix typo
* Checkpoint
* Fix indentation
* Use csc instead of mcs
* Checkpoint
* Fix BUILT_SOURCES only being handled for the first profile processed
* Checkpoint
* Checkpoint
* Strip double slashes from paths to fix spurious csproj change
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint: Fix genproj compilation
* Checkpoint
* Checkpoint
* Checkpoint
* Fix crash when no targets were loaded (due to an error)
* Checkpoint
* Checkpoint
* Checkpoint
* Fix TryParseTargetInto bug
* Checkpoint
* Shuffle exclude logic around so that it works correctly during genproj diffing
* Remove gensources tracing
* Checkpoint
* Fix handling of oddball sources paths from executable.make
* Fix jay not being set to build
* Fix wrong slashes being used for embedded resource paths
* [csproj] Update project files
|
|
* Modernize Windows random number generation.
- Less code.
- Less chance for failure.
- Not seedable.
- Requires Windows 7 or newer -- er, require Vista or newer until/unless Unity drops it, under ifdef.
This might get much further pruned with CoreFX import, which is on hold here, and doesn't really change much, except to indeed drop Vista support. (https://github.com/mono/mono/pull/9249)
|
|
lateralusX/lateralusX/windows-x64-llvm-support-master
Add LLVM AOT/Full AOT support on Windows x64.
|
|
* Helper scripts running mini regression tests in JIT/Full AOT on Windows.
A set of helper scripts running all mini regression tests, supporting both
JIT and full AOT (including building full AOT assemblies) using local build
Visual Studio mono runtime (can be switched in setp.env.bat). Includes logic
to pick correct Visual Studio toolchain and support to setup command prompt
targeting x64 full AOT build and running tests. NOTE, the scripts are not limited
to the mini regression tests, only includes a set of predefined assemblies making
it easier to execute regression tests.
Full AOT scripts includes capabilities to build dynamic library, static linked objects
or assembler output, it also supports switches to use LLVM when building full AOT
assemblies if supported by local build mono runtime.
By default, scripts follow default build configurations used by mono BCL builds and
Visual Studio x64 Release build mono runtime.
Examples to run all JIT regression tests:
run-jit-regression.bat all
To run individual programs using JIT (doesn’t need to be a regression test):
run-jit.bat [full path to assembly]
NOTE, for regression tests there is a shortcut making them easier to locate,
so then just the assembly name can be used, not the full path is needed.
run-jit.bat basic.exe
Examples to build all regression tests using full AOT:
build-full-aot-regression-tests.bat all
Builds all regression tests in full AOT including all needed support and
BCL assemblies. All build assemblies will end up in msvc\build\fullaot\winaot
folder by default. It is possible to build individual assemblies as well using:
build-full-aot-regression-tests.bat [full path to assembly]
NOTE, for regression tests there is a shortcut making them easier to locate,
so then just the assembly name can be used, not the full path is needed.
build-full-aot-regression-tests.bat basic.exe
Examples to run all regression tests using full AOT:
run-full-aot-regression-tests.bat all
Runs all regression tests in full AOT. It is possible to run individual assemblies
as well using:
run-full-aot-regression-tests.bat [full path to assembly]
NOTE, for regression tests there is a shortcut making them easier to locate,
so then just the assembly name can be used, not the full path is needed.
run-full-aot-regression-tests.bat basic.exe
There are some more features included in the scripts as well, but above shows
basic usage. It could also be possible to reuse the scripts in Visual Studio
build targets going forward to at least run the JIT regression tests
as part of Visual Studio build.
* Fixed some review feedback.
* Switching to 1 instead of -1 in case of errors.
* Used case insensetiv compare for some if's.
* Dropped use of ECHO OFF/ON in nested scripts.
* Removed clear of PATH (was not intended).
|
|
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.
|
|
|
|
This reduces our dependency on powershell.
|
|
* [mcs] Rename darwin paltform to macos
Darwin is common to both macOS and iOS/tvOS/watchOS, while we use the darwin platform only for macOS.
* [mcs] Add Unix platform for other Unixes than Linux
* [mcs] Remove PLATFORMS from xammac_net_4_5 since it only make sense on macos
* [bcl] Bump corlib version
* [csproj] Update project files
|
|
This PR adds the new files, moves the enums / structs and a small bit of code to validate the change.
|
|
Not sure what is happening here. Is the type incorrect throughout, or being passed to wrong function?
|
|
This PR introduces a new tool, gensources.cs, which replaces gensources.sh. It is able to parse the whole set of .sources files for a library in one go so that genproj can use that information to encode all our platform and profile specific files into one csproj file.
For now this PR just introduces it and switches libraries to using it instead of gensources.sh.
|
|
intrinsics.c file. (#8664)
|
|
without setting a platform (#8223)
* Default platform to net_4_x if none is specified, to fix tools that build without setting a platform
* [csproj] Update project files
|
|
If the runtime is configured using --enable-minimal=soft_debug, the debugger code will be compiled into a separate
libmono-dbg.a library which needs to be linked into the app. The debugger needs to be registered with the runtime by
calling mono_debugger_agent_init () before runtime initialization.
|
|
* [ci] Update csproj files during PRs
Similar to how API diff is done.
Replace EXTERNAL_DRAWING_FACADE in csproj in genproj
It'd embed the absolute path in the csproj, but we want the variable instead.
* [csproj] Update project files
|
|
|
|
|
|
We weren't emitting the postbuild script.
|
|
that were missing a profile (#7926)
Fixes #7903.
|
|
* [msvc] Update csproj files
* [msvc] Delete old net_4_x.csproj and xbuild_12.csproj files
|
|
* [genproj] Move obj to common folder and remove unnecessary properties
We now default to mcs/class/obj instead of writing to the assembly folder.
* [genproj] Fix jay path on Unix
* [genproj] Fix IntermediateOutputPath for Facades
|
|
* [monograph] Don't link duplicate copies of metadata and utils
Monograph builds against mono/mini/($LIBMONO_LA) (aka libmonosgen-2.0.la), so
the only pieces it would pick up from staticlly linking the extra libs are
non-API functions (such as the MonoClass getters), but at the cost of linking
errors due to duplicate symbols.
Also replace calls to MonoClass getters by mono API functions.
* [ilgen] Fixup MonoClass getter usage
Followup for e610e443cd67c78c2aeabef4209e380226dd65d5
* [boehm] Fix a few direct MonoClass accesses
* [monograph] Statically link against the mono runtime
Dynamically linking but using some symbols (such as mono_read32) on some
platforms that are hidden in the library means that we had to statically link
against the runtime anyway, which then caused build issues.
* [monograph] Fix runtime crash on startup
```
mono_os_mutex_lock: pthread_mutex_lock failed with "Invalid argument" (22)
```
* [msvc] Fix monograph build
|
|
|
|
This implements a simple deduplication of source files in the .csproj's.
A postprocessing step opens the files and grabs all ItemGroups with sources
and then does an intersection. It then moves files that are common
across all platforms into a separate ItemGroup.
|
|
This batch of commits makes further updates to our support for building the BCL using msbuild (Visual Studio, to be specific).
* Generates a single sln and set of csproj files with support for all of our build profiles (orbis, monodroid, net_4_x, etc)
* Project configuration selector (in VS or as parameter to msbuild) can be used to select which profile to build
* Includes partial dependency information so that culevel and jay are compiled before the rest of the sln (this keeps pre/post events from from failing on first build)
As of this rev things are working pretty good, but a lot of the measures I took here are temporary so I'd appreciate thoughts on how to go about them. The hard-coded System.Web -> Culevel dependency feels gross, for example - I kind of want to go through and build an automatic solution for it but I'm not sure it's necessary.
Implements #6858
---
* Checkpoint: Generate single .csproj file with conditional item/property groups
* Checkpoint: Updates to csproj and sln generation to support building specific profiles
* Move targets file in csproj template so that it isn't evaluated before all properties are set
* Checkpoint profile fallback (use net_4_x if project does not have appropriate profile)
* Use in-process cache for project guids to fix bug where many guids were being generated. Fix profile fallback.
* Clean up unnecessary debug writelines
* genproj error fixes
* Remove duplicate gacutil entry from makefile to fix order.xml corruption. Cleaner project names in msbuild sln. Compile genproj before generating inputs.
* Delete genproj.exe at beginning of update-solution-files because otherwise syntax errors will cause an old version to be used silently
Cleaner messages from genproj
* Hard-code the guid for culevel and add it as a dependency for system.web
* Bug fixes
* sln files are sensitive to whitespace format
* Don't generate pointless solution configurations if we have no information for them
* Updates based on PR feedback
|
