| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
* Fix error in vcxproj filter causing load error in Visual Studio.
* Fixes issue #7596 on Windows x64.
Passing value types in Windows x64 not fitting into register will be passed
by reference (ArgValuetypeAddrInIReg or ArgValuetypeAddrOnStack )
using a local variable allocated in caller’s frame.
Current implementation sized and marshaled the native struct correctly when
using pinvoke, but it sized the final local passed as reference to the native method
using the managed stack size instead of the native. This caused the final copy
into the local to overwrite other locals on stack if managed and native struct stack
sizes differed.
The fix is to flag the local variable used as stack parameter with its pinvoke state.
This makes sure the stack allocation size will be correct when using value types
passed on the stacks in pinvokes.
When running other unit tests with sequence points I hit a similar issue with
empty structs as return parameters (using [StructLayout (LayoutKind.Sequential, Size = 0)].
This commit includes a fix to ignore the return value if it’s an empty struct on Windows x64.
|
|
* [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
|
|
* gboolean g_is_usermode_native_debugger_present (void).
i.e. Win32 IsDebuggerPresent which is just call mov mov ret.
Other slower methods on other systems if possible and unintrusive (OSX).
This is very useful as in:
if (g_is_usermode_native_debugger_present ()) G_BREAKPOINT
"native" meaning "not managed"
"usermode" meaning "not kernel"
Both other kinds exist and are detected differently.
* Move new debugging utility from glib to mono/utils.
* Redo it with CoreCLR as basis. https://github.com/dotnet/coreclr/blob/master/src/pal/src/init/pal.cpp
* Link to a specific stable revision, not master.
https://raw.githubusercontent.com/dotnet/coreclr/f1c9dac3e2db2397e01cd2da3e8aaa4f81a80013/src/pal/src/init/pal.cpp
* Use a clearer form of boolean normalization.
* Update Visual Studio project files.
* Fix include path, remove unnecessary boolean canonicalization, spell out words, swap int/boolean.
* Header got missed in the move from glib.
|
