Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/mono.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/msvc
AgeCommit message (Collapse)Author
2019-10-14[loader] Move PInvoke and DllMap code into separate source fileRyan Lucia
2019-10-09Running --enable-msvc-only didn't find jay.vcxproj. (#17228)Johan Lorensson
2019-10-08Clean up map.c /map.h (#16746)Steffen Kieß
* [Mono.Posix] Move Mono_Posix_{From,To}MremapFlags() to support/sys-mman.c Since b522eab5ff5466debaacf9e971e26cfc464ebba5 Mono_Posix_FromMremapFlags() and Mono_Posix_ToMremapFlags() contain manual changes for NetBSD. Move the functions from support/map.c to support/sys-mman.c so that they won't be overwritten when create-native-map is rerun. * [Mono.Posix] Fix prototypes in support/stdio.c In ed892ccf27849c082ce6ca46fa8b96d86ca7c329 wrapper functions for several stdio functions were added, but the prototypes in map.h were manually written, not using create-native-map. This commit changes the prototypes so that they match the output of create-native-map. * [Mono.Posix] Undefine HAVE_STRUCT_SOCKADDR_IN6 in support/map.c on MSVC In 22b6b9581418260397b701c17b16c3eb55136de7 a manual change to support/map.c was added to prevent Mono_Posix_FromSockaddrIn6() and Mono_Posix_ToSockaddrIn6() from being built for windows even if HAVE_STRUCT_SOCKADDR_IN6 is defined. Instead undefine it in a header file to avoid manual changes to map.c. With this commit map.c, map.h and NativeConvert.generated.cs contain no manual changes anymore.
2019-10-03Optional only build MSVC runtime using make file system on Windows. (#16915)Johan Lorensson
* Build MSVC only runtime using make file system. Add a new option to only build MSVC version of mono runtime and native tools, --enable-msvc-only. In the past, --enable-msvc build both mingw as well as MSVC runtime, this commit adds an option to only build MSVC version of runtime and native tools using make file system. Commit updates all native make file making sure mingw/gcc builds are not done if --enable-msvc-only has been used. It also makes sure we build and use MSVC based tools as part of build and tests. Result will be a build without any mingw/gcc artifacts, but where all existing make files still works with the MSVC build artifacts. This commits is also preparing to switch the .NETCore build over to use MSVC build runtime in order to get LLVM support, something that is currently only supported on Windows MSVC build. * Add link to mono-sgen.exe and clean windows binaries. * Fix failures in mono/tests test-aot on Windows. * Add fullaot-mixed tests on Windows x64. * Run msbuild in parallel. * Default to x64 mingw host on cygwin build.
2019-09-12[netcore] Create a separate version of threadpool.c for netcore with the ↵Zoltan Varga
domain support removed. (#16250) * [netcore] Create a separate version of threadpool.c for netcore with the domain support removed. * Fix the windows build. * Fix the build.
2019-08-24Remove dlmalloc from Win32. (#15773)Jay Krell
2019-08-17Fix the windows build.Zoltan Varga
2019-08-01Support proper Windows kernel Unicode thread names. (#15919)Jay Krell
These do not require a debugger, can be retrieved, appear in ETW, etc. Extracted from https://github.com/mono/mono/pull/15859.
2019-07-31[zlib] Fix typo in readme and remove deleted file from msvc projectsAlexander Köplinger
2019-07-31Update zlib from 1.2.5 to 1.2.11. (#15480)Jay Krell
Circa 2010 to circa 2017. Retrieved with apt-get source zlib on WSL Ubuntu 18.04.2 LTS. This matches Debian or Ubuntu (they differ by one commit, and one of them restores a dummy function for compat). --- * [minizip] Ensure we don't ever accidentally change calling convention Make sure we always #define ZCALLBACK to empty so we don't change the calling convention on windows by including a header which defines 'CALLBACK'. This will keep things as cdecl as required by the c# pinvokes. * Update zlib readme. * Update zlib from 1.2.5 to 1.2.11. * [zlib] Small fix for Visual C++. see https://github.com/madler/zlib/pull/435/files#diff-0558e84b0c24a83ca790dcb05cd26212R1087 and https://github.com/madler/zlib/pull/435/files#diff-0558e84b0c24a83ca790dcb05cd26212R1104 * Add gzguts.h to Makefiles. * Add .h files to Visual Studio project files just for GUI purposes.
2019-07-24Remove traces of w32process-win32-internals.h which was deleted by previous ↵Alexander Köplinger
commit
2019-07-19[metadata] Fix name of header fileAlexander Köplinger
The file added as part of d5b374bb51a07bf3525d63b4cef6ad6979c27d07 was actually called loaded-images-internals.h
2019-07-18[loader] Add MonoAssemblyLoadContext; stop sharing MonoImages on netcore ↵Aleksey Kliger (λgeek)
(#15527) Implement a couple of things: 1. Add a `MonoAssemblyLoadContext` opaque struct 2. On netcore Mono, use it to keep track of which `MonoImage`s are loaded. (Addresses part of #13891) In a bit more detail: - Add a `MonoLoadedImages` struct to hold the hash tables that we use for checking if a `MonoImage` is already loaded - Add an opaque `MonoAssemblyLoadContext` typedef - (Framework Mono) Add a `get_global_loaded_images()` function to get the shared `MonoLoadedImages` - (netcore Mono) Add a `MonoAssemblyLoadContext` struct that owns a `MonoLoadedImages` and add a `default_alc` member to `MonoDomain - Pass a `MonoAssemblyLoadContext*` to most `MonoImage`-loading functions - on Framework Mono its usually NULL and we fall back to the global loaded images, on netcore Mono it's usually `domain->default_alc->loaded_images` - (netcore Mono) Create a default Assembly Load Context when a `MonoDomain` is created - Add a `MonoAssemblyLoadContext*` field to `MonoAssemblyLoadRequest` and pass an ALC in a few places. --- Remaining work: (netcore Mono) There are still places where a `MonoAssemblyLoadRequest` or a `MonoAssemblyOpenRequest` has a `NULL` ALC - those will need to be tracked down and fixed. (netcore Mono) Eventually `MonoAssemblyLoadContext` should keep track of the loaded `MonoAssembly`s, not just images. One goal on netcore Mono is to ifdef out `MonoDomain:domain_assemblies`. --- * [loader] Add a MonoLoadedImages struct to own the MonoImage sharing Initially, there's just a single global set of loaded images. Once we have AssemblyLoadContext support, each ALC will have a separate set. NOTE: - Some of the existing Mono API is difficult to support with this design since it assumes each MonoImage is loaded at most once. * [loader] Add a MonoAssemblyLoadContext member to MonoImage for netcore * [loader] Unregister image from its owner when closing * [loader] Pass MonoLoadedImages to register_image * [domain] Add mono_domain_default_alc and mono_alc_get_loaded_images * [loader] Add an AssemblyLoadContext argument to mono_image_loaded_internal * [metadata] Add mono_image_get_alc () * [loader] Pass MonoAssemblyLoadContext to mono_image_open_from_data_internal * [loader] Pass MonoAssemblyLoadContext to mono_image_open_from_module_handle * [loaded] Pass MonoLoadedImages to mono_image_open_a_lot_parameterized * [loader] Pass MonoAssemblyLoadContext to mono_image_open_a_lot * [runtime] Mark mono_image_open_full external only Runtime should use mono_image_open_a_lot. * [runtime] Mark mono_image_loaded_by_guid external only Also mark mono_image_loaded_by_guid_full external only Runtime will need some (as yet unwritten) mechanism that takes a MonoAssemblyLoadContext as an argument. * [domain] Create a default ALC for each MonoDomain * [netcore] Pass default ALC in mono_core_preload_hook If the assembly name matches a trusted platform assembly, open it in the default ALC of the root domain * [mini] Open main assembly in default ALC in the root domain * [netcore] Don't define get_global_loaded_images() Every assembly load request should come from an assembly load context. Each ALC has a set of loaded images. So we should never need a global list. With this PR, we no longer share MonoImages across distinct ALCs. So in principle, each ALC can open the same assembly but resolve its references in different ways. Fixes part of https://github.com/mono/mono/issues/13891 * [runtime] Mark mono_pe_file_open external only * [loader] Pass MonoAssemblyLoadContext to mono_image_open_raw and mono_image_open_metadata_only * [loader] Pass MonoAssemblyLoadContext to do_mono_image_open and set MonoImage:alc * [loader] Add version 2 of assembly preload hook Pass MonoAssemblyLoadContext through the preload hook. This is used in mono_assembly_request_byname_nosearch which, in turn, is called by load_reference_by_aname_default_asmctx which is used to resolve references from one assembly to another. * [netcore] Pass native ALC ptr to AssemblyLoadContext.InternalLoadFile * [netcore] Implement AssemblyLoadContext.InternalInitializeNativeALC also implement mono_domain_create_individual_alc () * [netcore] Pass ALC to System.Reflection.Assembly.InternalLoad Pass the domain default ALC to mono_assembly_load () Also pass MonoAssemblyLoadContext to mono_assembly_load_full_gac_base_default () * [loader] Implement MONO_LOADED_IMAGES_ASSEMBLY properly Store the MonoLoadedImages for netmodules in the MonoImage for the main image of an assembly. This is also used by SRE - the dummy module of the AssemblyBuilder has the loaded_images that contains the ModuleBuilders. * [loader] Use global_loaded_images for netmodules with framework Mono The new stuff is only for ALC support in netcore * [loader] Drop netmodule support in MonoAssemblyLoadContext netmodules are not supported in netcore * [loader] Spin out image hashing out of image.c Move MonoLoadedImages support code to loaded-images.c loaded-images-global.c and loaded-images-netcore.c Also spin out assembly-load-context.c for MonoAssemblyLoadContext functions * Move ALC icall to assembly-load-context.c * formatting fix * [msvc] Add new files to .filters * update comments * [image] Change mono_loaded_images_remove_image to decrement the refcount Decrement the refcount and remove the image from the loaded images hashes in one place. Change mono_loaded_images_remove_image to return TRUE if the rest of image unloading should proceed or not. * [loader] Drop unused argument to mono_alc_init
2019-07-05Win32 zlib support. (#15509)Jay Krell
Fixes https://github.com/mono/mono/issues/15503 Always statically link on Windows (msvc and mingw). This is a somewhat old zlib, and will be updated shortly (https://github.com/mono/mono/pull/15480) Note that zlib is not valid C++, so always compile as C.
2019-07-02Add support for TLS callbacks on Windows. (#15423)Johan Lorensson
* Add support for TLS callbacks on Windows. Mono runtime depends on DllMain to be called by OS in order to correctly detach threads from the runtime. If this doesn't happen, threads from native thread pools (not owned by runtime) and attached using native->managed callback, won't detach resulting in attached threads no longer running. Since threads are still attached to runtime, next GC will try to suspend the thread and that will fail and that in turn will put the state machine in an incorrect state, bringing down the runtime at next GC (when the thread state is revisited). This problem is currently handled by DllMain, but since DllMain only exist in DLL's, statically link Mono runtime will get us into the above scenario. This commit add support to hook up a TLS callback using the same mechanism used by MSVC linker and c-runtime (also available under MINGW). The callback will be included in a section/segment of an object file and included in final image (DLL or EXE) by linker and called by OS loader, solving the problem with static linked Mono runtime not being able to detach terminating threads. The commit keeps current DllMain method when building a DLL but includes a mechanism making sure we only use one of the callback techniques at runtime, if both have been included in final image. This will simplify the build of libmini since we can always build the object including the callback, regardless how the library will be consumed.
2019-06-25[aot profiler] Listen for commands on given port (#14936)Radek Doulik
* [aot profiler] Listen for commands on given port Extended the aot profiler so, that it can receive commands over the network. Added new option `port=PORT`, which enables command server and specifies the port the server should listen at. We have 2 commands so far. save ... save the profile data to socket and close it quit ... quit the profiler. it also saves the profile to the file in case the output option was specified. It makes the aot profiling much easier to use on Android as we don't need to save the profile to a file on the device. That means we don't need to set `<application android:debuggable="true"/>` flag, which changes the Android app behavior and thus influence the profile itself. It is also convenient way for IDEs to retrieve the aot profiles. Example use for Xamarin.Android. Save and receive the profile data: adb shell setprop debug.mono.profile aot:verbose,port=9999 adb forward tcp:9999 tcp:9999 nc -v 127.0.0.1 9999 > profile.aotprof found 0 associations found 1 connections: 1: flags=82<CONNECTED,PREFERRED> outif lo0 src 127.0.0.1 port 50398 dst 127.0.0.1 port 9999 rank info not available TCP aux info available Connection to 127.0.0.1 port 9999 [tcp/distinct] succeeded! save Check what we received: aotprofile-tool -sd profile.aotprof Modules: 132475FF-85AA-430D-913C-7642CBD8587E mscorlib F7BDCAB5-83D3-4A0A-A33D-BBE94284667D Mono.Android 22897151-27C9-4064-B001-8A04F5847812 System AA3FC224-D486-4304-A8C9-EBF316556B26 Java.Interop 00D98403-051B-4168-A391-F3F601637CBD System.Core FD06519A-C321-426C-BDD8-C97777452057 xat_latests_and_greatest_vsmac_8._1 9ECB003E-D449-438B-BE35-58810DCBC917 Xamarin.Android.Support.v7.AppCompat 11659962-EFAC-400D-9F8D-AF925B26AE41 Xamarin.Android.Support.Fragment 48C436F7-611D-470D-9949-AC13FFDCF613 Xamarin.Essentials 2792D10D-7E13-46E6-BB4A-933C25635F48 Xamarin.Android.Support.Design Summary: Modules: 10 Types: 221 Methods: 932 * Try to fix WIN32 compilation * Add helper.c to mono-profiler-log.vcxproj * Add helper.c to mono-profiler-log.vcxproj.filters as well
2019-06-21[api] Add a mono/metadata/profiler-legacy.h header (#15098)Aleksey Kliger (λgeek)
* [api] Add mono/metadata/profiler-legacy.h header Add a header with the legacy Mono profiler API. New code should use the API from mono/metadata/profiler.h. * [profiler] Mark the legacy profiler API with MONO_DEPRECATED * [runtime] Don't install the profiler-legacy.h header Make the decision later whether these should be in the set of public API headers
2019-06-13Propagate error in mono_unicode_to_external (#14879)Ryan Lucia
* Add internal version of mono_unicode_to_external to propagate error * Migrate things to _error version where sensible * Remove redundant goto * Print input string when conversion fails * Remove todos * Switch everything to MonoError * Naming: err -> error * Actually print out *filename correctly
2019-06-04Increase main thread stack size on Windows.lateralusX
On Windows default thread stack size has been 1MB for a long time (both 32/64-bit). When starting to use interpreter some of the tests include deep recursions that will hit stackoverflow on Windows (ackermann.exe as one example). This commit adjust the default reserved stack size to 8MB for debug builds and 1.5MB (same as coreclr), for main thread only. All other threads will still default to 1MB stack size (both debug/release).
2019-05-29Infrastructure support / fixes for making compiler server the default (#14279)Katelyn Gadd
* Fix enabling the compiler server using autogen, and force it off if mcs is being used * autogen updates * Formatting fixes * Fix vbcs getting turned on if unspecified even if mcs was selected * Dynamically evaluate ENABLE_COMPILER_SERVER each time we compile instead of evaluating it once at some arbitrary point during makefile evaluation * More detailed comment based on testing * Handle the /shared option in genproj so it doesn't fail * Raise basic profile check requirement to 6.2 and hopefully assert that named pipes work * Default compiler server to off for now.
2019-05-27Add missing new files to Makefile.am, fix tarball build (#14656)Alexander Köplinger
They were added in https://github.com/mono/mono/pull/14427
2019-05-16Fix Windows Mono LLVM build error on nightly master build.lateralusX
2019-05-10Merge pull request #14425 from lateralusX/lateralusX/fix-profiler-on-windowsJohan Lorensson
Add log profiler support to Mono MSVC build.
2019-05-10Merge pull request #14332 from ↵Johan Lorensson
lateralusX/lateralusX/add-llvm-windows-msvc-build-packaging-support Add LLVM Windows MSVC build/packaging/archive/download support.
2019-05-10[netcore] Enable MSVC builds of Mono w/ ENABLE_NETCORE (#14418)Filip Navara
* Enable MSVC builds of Mono w/ ENABLE_NETCORE * Fix non-netcore build * Move the ENABLE_NETCORE definition to config.h where it belongs * Replace .def with linker #pragmas * TARGET_WIN32 -> HOST_WIN32 && HOST_X86 * Pick up MONO_ENABLE_NETCORE from cygconfig.h * Make `./configure --with-core=only` MSVC builds working * Include netcore sources unconditionally, move the condition into the .c file * Fix MSVC C++ netcore build on Win32
2019-05-09Add log profiler support to Mono MSVC build.lateralusX
Several fixes to the log profiler in order to work on Windows. * Add new dynamic library project to build log profiler on Windows MSVC. * Fix dependecy between log profiler and Mono. * Rewrite command pipe logic on Windows since it's not supported to select on both sockets and pipes. * Several additional socket fixes needed for log profiler to work on Windows.
2019-05-09Introduce enum and static data for JIT icalls, that are currently hashed ↵Jay Krell
(#14359) * Introduce enum and static data for JIT icalls, that are currently hashed by string and address and use dynamic allocation. These will be used shortly. * PR: Move MONO_JIT_ICALLS content from class-internals.h to jit-icall-reg.h. Not clear what is the best name but moving along.
2019-05-04Add execute permissions on build scripts.lateralusX
2019-05-03Add option to restore VS build env from file.lateralusX
2019-05-03Add support for cygwin and WSL in helper build scripts.lateralusX
2019-05-03Add support to include external build LLVM binaries in Mono build output.lateralusX
2019-05-03Add LLVM SDK build/package support for Windows msvc build LLVM.lateralusX
2019-04-24Add hybrid/cooperate runtime support on Windows.lateralusX
2019-04-08Make sure additional supported enable defines ends up in config.h on Windows.lateralusX
2019-03-27Delete monograph. Closes https://github.com/mono/mono/issues/7845Jo Shields
2019-03-25[windows]Fix and cleanup configure.ac parsing for MONO_CORLIB_VERSION and ↵Jay Krell
ACINIT. (#13630) Not just a guid or an uppercase guid.
2019-03-21Adjust genconst to changes in winsetup.bat. (#13554)Johan Lorensson
When logic moved from winsetup.bat into an msbuild task that changed the console output of winsetup.bat causing problems for genconst to find MONO_VERSION and MONO_CORLIB_VERSION. There was also a potential problem where winsetup.bat couldn't find msbuild.exe if not included in PATH. This fix makes sure winsetup.bat detect and setup a full msbuild environment before running msbuild.exe. It also change genconsts to look at the generated config.h for the correct values of MONO_VERSION and MONO_CORLIB_VERSION that will be used by the runtime builds.
2019-03-18Remove more unnecessary nunit24 cruftAlexander Köplinger
2019-03-15Windows full AOT build scripts update.lateralusX
* Only do clean/rebuild when an assembly changed. * Add wrappers for different full AOT build configurations. * Make scripts callable from different working directory.
2019-03-12Move drawing types for XI/XM/wasm/orbis/unreal to System.Drawing.Common (#13414)Alexander Köplinger
* Move drawing types for XI/XM/wasm/orbis/unreal to System.Drawing.Common For XI/XM they were in Xamarin.iOS.dll/OpenTK-1.0.dll before. For wasm/orbis/unreal we remove System.Drawing.dll from the profiles and add the types to System.Drawing.Common.dll instead to align with the other mobile profiles (only "net_4_x" and "build" still have System.Drawing.dll). * Bump API snapshot submodule * [csproj] Update project files
2019-03-08Include mono-forward.h public header on Windows.lateralusX
2019-03-06[gitattributes] Do CRLF normalization on sln/proj filesAlexander Köplinger
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.
2019-02-27Add atexit-waitforkeypress handler in Visual Studio mono.sln test projects ↵lateralusX
run args.
2019-02-18Set executable bit for all .sh files in repoAlexander Köplinger
2019-02-18Correct access permissions to include "user execute" for run-msbuild.sh. ↵bwadswor
(#13042) Correct access permissions for run-msbuild.sh. Adding "user execute" seems to fix the following build error. With this change I'm able to build on windows in Cygwin. without, I see the below error: ``` $ make -j4 (CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /cygdrive/c/mono/mono/missing autoheader) rm -f stamp-h1 touch config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged Git submodules updated successfully make all-recursive make[1]: Entering directory '/cygdrive/c/mono/mono' Making all in msvc make[2]: Entering directory '/cygdrive/c/mono/mono/msvc' Building Mono runtime using Visual Studio. ../msvc/run-msbuild.sh "build" "i686" **/bin/sh: ../msvc/run-msbuild.sh: Permission denied** make[2]: *** [Makefile:614: all-local] Error 126 make[2]: Leaving directory '/cygdrive/c/mono/mono/msvc' make[1]: *** [Makefile:583: all-recursive] Error 1 make[1]: Leaving directory '/cygdrive/c/mono/mono' make: *** [Makefile:513: all] Error 2 ```
2019-02-05Add better support to dynamically setup content of config.h in Windows MSVC ↵lateralusX
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.
2019-02-01Add support for Windows x64 winaot, winaot_llvm builds/tests on CI. (#12601)Johan Lorensson
Add support for building Windows x64 fullaot version of winaot profile that can be run on CI. Initial changes also add execution of mini regression tests on CI. More tests will be added going forward and when having full pass rate. Add support for building Windows x64 fullaot+llvm version of winaot profile that can be run on CI. Initial changes also add execution of mini regression tests on CI. More tests will be added going forward and when having full pass rate. In order to get deterministic build results and working build on CI, we need to setup a correct build environment for the MSVC builds. Since MSVC build is currently run from cygwin, there are environment problems, both general but also in our CI environment, since we add cygwin bin folder to system path (needed by Jenkins plugin). When running more complex cmake builds like BTLS and LLVM, this will cause problems picking up incorrect tools, failing builds on CI. Another problem is the AOT compilation using MSVC toolchain. In the past CI used some "hard coded paths" to make sure clang.exe and link.exe was found. This is not optimal and won't work when including LLVM as part of full AOT since link.exe will need access to more of the full build environment setup by VS development environments (like platform libraries). In order to get a better build environment on CI this commit includes and enhance a couple of build scripts used to run msbuild.exe and mono-sgen.exe (as AOT compiler) in a VS development environment, isolate that build process from cygwin environment. The build scripts will locate installed VS tooling, VS2015 build tools or VS dev env, VS2017 build tools or VS dev env and use corresponding development environment scripts as part of running msbuild.exe and mono-sgen.exe in AOT mode. In order to make sure mono-sgen.exe as AOT compiler is run through these scripts an additional environment variable MONO_EXECUTABLE_WRAPPER is introduced and used in mono-wrapper when set. Without this indirection there will be problems on CI tests since the environment is using MONO_EXECUTABLE and pass that into for example test driver that run child processes of mono-sgen.exe, meaning that we can't use scripts for MONO_EXECUTABLE, but splitting the MONO_EXECUTABLE to represent mono runtime and have a MONO_EXECUTABLE_WRAPPER that could be a launch script solves this issue. This commit also includes several smaller fixes made to the generic fullaot build infrastructure. Fix additional msbuild arguments. Add Mono.SIMD assembly to winaot profile. Run msbuild.exe as part of .bat file.
2019-01-17[llvmonly] Refactor llvmonly runtime support code by moving it to a separate ↵Zoltan Varga
file. (#12436) * [llvmonly] Move all runtime support code to a new llvmonly-runtime.c file. * [llvmonly] Make mini_init_delegate () work in mixed mode, it needs to initialize both the interp and the llvmonly related data. * [llvmonly] Implement EH support in mixed mode. On interp->native transitions, add a try-catch. On native->interp transitions, rethrow the exception using a c++ throw. * [llvmonly] Unify function naming, name all llvmonly runtime functions mini_llvmonly_. * Fix a build failure. * Fix windows build. * Fix an aot failure. * Fix the EH changes.
2019-01-15Merge pull request #12317 from ↵Johan Lorensson
lateralusX/lateralusX/fix-warning-errors-win64-platform Fix warning and build errors triggered in win64 platform that doesn't define HAVE_CLASSIC_WINAPI_SUPPORT.
2019-01-14[bcl] Embed Source Link information (#12403)Alexander Köplinger
Source Link allows IDEs/debuggers to retrieve a source file from a remote location like GitHub when the local file isn't available. Specification: https://github.com/dotnet/designs/blob/e55c517a1e7f8dc35b092397058029531209d610/accepted/diagnostics/source-link.md For now we only embed info about mono, cecil, corefx and corert since that covers 99% of what you usually want to debug and doesn't need fancy logic that reads git submodules and figures out their URLs. Should enable use cases like https://twitter.com/jlaban/status/1084248087802060801