| Age | Commit message (Collapse) | Author |
|---|
|
They are no longer needed here.
|
|
|
|
This allows us to remove a lot of cruft and simplifies our CI build.
|
|
This reverts commit 8e82ce21b607f57f2f4889c81edd9c9813530a3f.
|
|
* [mono][debugger] First PR to implement iCorDebug on mono
The goal of this PR is change the current files to support the implementation of iCorDebug on mono:
- Split debugger-agent into debugger-protocol and debugger-agent, debugger-protocol will be used in the next PR in mscordbi implementation.
- Fix strings with the meaning of the commands, there were missing strings and then the PRINT_DEBUG_MSG was printing wrong information.
- On debugger-engine pass the offset of the IL when stop in a breakpoint.
- Created a new protocol major version to support the changes that we need to implement mscordbi.
- When mono debugger is started with server=n will waint until the timeout for a server to connect, this is necessary because depending on how we will launch the process with iCorDebug implementation, maybe mono will start before the debugger server(mscordbi).
|
|
|
|
|
|
Move C version of EventPipe library into a folder that can be shared by both CoreClr and Mono:
src/native/eventpipe
All runtime specific EventPipe files (shim implementation, build files etc) will be kept under each runtime (mono/mono/eventpipe for example). Example on how shared EventPipe sources will be consumed by mono build, src/mono/mono/eventpipe/CMakeLists.txt.
PR also adds ability to build mono/mono/eventpipe/test using CMake (needed after mono switched to cmake). Tests are still mono specific so will be kept there for now, but will most likely be shared between runtimes at a later point in time.
@jkotas @stephentoub Do you believe the location of new folder where we can share native code between runtimes is OK, src/native/eventpipe?
@lambdageek @josalem
Co-authored-by: lateralusX <lateralusX@users.noreply.github.com>
|
|
shim. (#20570)
Adjustments done to better align with implementation of CoreCLR shim using CoreCLR artifacts and C++ code (CoreCLR implementation done in separate PR).
Disconnect runtime specific shim info from shared sources, all included shim files handled through defines.
Exception safety and improved error handling, adding error checking and error returns into shim container functions.
Walkthrough of codebase, aligning with gaps from CoreCLR + port of sample profiler and json file serializer.
Implement core dump diagnostic command and runtime layer (needed by CoreCLR, currently not implemented on Mono).
Implemented process env diagnostic command and runtime layer.
Implemented profiler attach diagnostic command and runtime layer (needed by CoreCLR, currently not implemented on Mono).
Fix native EventPipe test aligning with changes.
@lambdageek @josalem
Co-authored-by: lateralusX <lateralusX@users.noreply.github.com>
|
|
Building full AOT using CI scripts won't work when VS2019 IDE is
present (not falling back to VS2019 build tools).
This happens due to a typo in setup-vs-msvcbuild-env.bat. Since CI
doesn't install VS IDE, but using buildtools (where clan bin
path is added to PATH) problem only shows up on local development
environment using VS2019 IDE.
|
|
* [runtime] Add an options API.
Add a general options API to the runtime, based on the flags API in Google V8:
```https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/src/flags/```
Supported features:
* Definition of runtime options in a declarative way.
* Options are mapped to C globals.
* BOOL/INT/STRING data types.
* Generic option parsing code.
* Generic usage code.
* Read-only flags for build-time optimization.
This is designed to replace the many option parsing functions in
the runtime, MONO_DEBUG, the many mono_set_... functions etc.
* Address review comments.
* Fix the c++ build.
* Fix the windows build.
* Fix the windows build.
* Update comments.
* Rename flags->options.
* Fix the windows build.
* Disable example options.
* Rename the option variables to mono_opt_<name>.
* Update mono/utils/options.c
Co-authored-by: Aleksey Kliger (λgeek) <akliger@gmail.com>
Co-authored-by: Aleksey Kliger (λgeek) <akliger@gmail.com>
|
|
|
|
* Extend w32subset API usage.
* Fix C++ build error.
* Remove HAVE_SYSTEM from w32subset.h.
* Use relative path for w32subset.h in eglib.
* Move w32subset.h into utils.
|
|
potentially shared between runtimes. (#20351)
PR handling port of Diagnostic Server C++ library from CoreCLR into a C library that can be shared between Mono as well as CoreCLR runtime. Port follows same guidelines setup for event pipe port dotnet/runtime#34600. Diagnostic server library is currently hosted as part of event pipe library but hosting its own runtime shim as well as source files (so could be split into separate library if ever make sense). Diagnostic Server have dependencies on event pipe library (and reuse part of event pipe runtime shim from its own shim).
This is the first PR getting the code from diagnostic server codebase over to C library. Once that is done there will be follow up PR's starting to enabling more of the CoreCLR tests suites over event pipe currently depending on diagnostic server and connection between diagnostic server and event pipe library.
Diagnostic server processinfo, https://github.com/dotnet/runtime/tree/master/src/tests/tracing/eventpipe/processinfo, test pass running on Windows/Linux Mono.
eventpipe buffersize, https://github.com/dotnet/runtime/tree/master/src/tests/tracing/eventpipe/buffersize, test pass running on Windows/Linux Mono, connecting diagnostic server with eventpipe and IPC test clients and parsers.
TODO's before this PR can be merged:
- [x] Fix all builds (currently only validated on Windows).
- [x] Port POSIX PAL.
- [x] Get pass on process info on Linux/Mac enabling the test as part of PR.
- [x] Implement WriteEvent icall as well as starting IPC streaming thread in event pipe library.
- [x] Get pass on one test consuming event pipe data over IPC.
Co-authored-by: lateralusX <lateralusX@users.noreply.github.com>
|
|
domain (#20338)
These commits:
* Add the MonoMemoryManager struct
* Create a memory manager in every domain on legacy
* Create a memory manager in every ALC on netcore
* Update callers accessing the fields in the domain directly
* Remove lazy initialization on some of the old domain fields, in the interest in code simplification
* Put the lock protecting the MemoryManager fields inside the struct itself
Everything is still allocated at the domain level, either from the domain or default ALC depending on legacy vs netcore.
This and the follow up PR have potential to expose racy locking logic by not taking the domain lock as frequently, but if that comes up we can just readd the domain lock as needed alongside the memory manager lock.
Co-authored-by: CoffeeFlux <CoffeeFlux@users.noreply.github.com>
|
|
These are mostly around string operations and are meant to be a quick boost in performance for some common blazor scenarios, around rendering and json parsing, before interp optimizations catch up. Even if the interpreter will have more advanced optimization passes, it is likely that it would still be much slower on these low level operations. Long term we would have methods like these AOT-ed, but, depending on how easy to maintain and how effective these turn out to be, we could also stick to intrinsifying some bcl code in the future.
Co-authored-by: BrzVlad <BrzVlad@users.noreply.github.com>
|
|
(#19958)
Continuation of https://github.com/dotnet/runtime/pull/34600, adding BufferManager into the library including unit tests, merging source files and additional library restructuring.
- Port EventPipeBuffer.
- Port EventPipeBufferList.
- Port EventPipeManager.
- Merge internals source files. Changed GETTER_SETTER to only mandate use of inlined functions when calling betweeen source files for different types. Upgraded all use within each source file for direct struct access.
- Changed function entry error checkin strategy. Only apply active checks on outer library API, ep.h, and use EP_ASSERT for all other functions.
- Dropped requires_lock_held in function naming, switch to comment in header or in forward declare for functions that validates that lock is held.
- Removed currently unused GETTER/SETTERS.
- Moved more comments into sources from corresponding CoreCLR EventPipe sources.
- Add EventPipeBuffer/EventPipeBufferManager unit tests.
Next step after this PR will be to enable a file session during runtime and add more unit tests and then start getting diagnostic server component over to Mono.
Co-authored-by: lateralusX <lateralusX@users.noreply.github.com>
|
|
support (#19927)
Covariant return implementation for Mono.
---
There are also a couple of general Mono fixes in here, too:
1. Interpreter support for `MONO_TYPE_FNPTR` in `mint_type()`
2. a "signature assignment" mode for `mono_class_is_assignable_from` that doesn't treat `IntPtr[]` and `long[]` (or `int[]`) as interchangeable
3. support for unmanaged pointer comparisons in `mono_class_is_assignable_from`
4. Factor `mono_byref_type_is_assignable_from` out of `ves_icall_RuntimeTypeHandle_type_is_assignable_from` and make it generally usable.
---
For covariant returns, there are a couple of pieces here:
1. Method overrides come in two flavors: implicit (matching by name and sig) and explicit (using a `.override` directive).
* for explicit overrides, we have to check that the override has a signature that is subsumed by (its return type is a subtype of the return type of) the previous override, if any, and the declared method.
* for implicit overrides, we have to check that the override has a signature that is subsumed by the previous most derived override (not just the one that we happened to find with a precisely matching signature).
2. If any override is marked by `[PreserveBaseOverridesAttribute]` then we need to find all the other slots that may have methods from the override chain and update them. (The attribute is expected to be applied to a `newslot virtual` method that is an explicit `.override` of some other method).
There's an interesting test case where a class has _both_ an implicit and and explicit override for the same slot, arrived via different methods - in this case, the implicit one is supposed to be ignored. We implement this by doing the implicit slot filling first, then the explicit, and saving the covariant return checking until after both are done.
---
Because the method (`MethodImpl`) is both an override of another virtual method,
and is itself a `newslot`, it will occupy (at least) 2 slots in the vtable -
its own newslot and the `MethodDecl` that it is overriding.
If a third class subclasses the class with the `MethodImpl` or one of its
descendents and itself overrides either the `MethodDecl` or (one of the)
`MethodImpl` (either implicitly or with another explicit .override) the
`PreserveBaseOverridesAttribute` is a signal to apply the new override that it
should apply to all the slots.
The way this works is when processing the overrides, we walk up the class
hierarchy looking at the contents of the impl slot and if any of them have the
attribute, we make sure to add a mapping to the "`override_map`" to replace any
occurrences of a previous impl with the newest (most derived) impl.
An (existing) later pass goes through the vtable and applies the override_map.
Contributes to dotnet/runtime#37509
* [metadata] Implement support for PreserveBaseOverridesAttribute
The attribute is expected to be applied to a `newslot virtual` method that
is an explicit .override of some other method.
Becuase the method (MethodImpl) is both an override of another virtual method,
and is itself a `newslot`, it will occupy (at least) 2 slots in the vtable -
its own newslot and the MethodDecl that it is overriding.
If a third class subclasses the class with the MethodImpl or one of its
descendents and itself overrides either the MethodDecl or (one of the)
MethodImpl (either implicitly or with another explicit .override) the
PreserveBaseOverridesAttribute is a signal to apply the new override that it
should apply to all the slots.
The way this works is when processing the overrides, we walk up the class
hierarchy looking at the contents of the impl slot and if any of them have the
attribute, we make sure to add a mapping to the "override_map" to replace any
occurrences of a previous impl with the newest (most derived) impl.
An (existing) later pass goes through the vtable and applies the override_map.
* add FIXME for dynamic images
* scan entire chain of inheritance, don't stop at the class with the attribute
Makes OverrideMoreDerivedReturn.il pass
* UnitTestDelegates is also passing
* [metadata] Add mono_metadata_signature_equal_no_ret
* inflate signature->ret when doing covariant checking
* [class] Add mono_class_signature_is_assignable_from_checked
In ECMA I.8.7.1 "assignment compatability for signature types" we need to
distinguish IntPtr[] from int32[] and int64[]. The ordinary cast_class for an
array type in Mono implements the "intermediate type" relation from I.8.7.3
"general assignment compatability" - IntPtr[] gets treated as inter-castable
with int32[] or int64[], depending on platform pointer size.
The new mono_class_signature_is_assignable_from_checked function does the finer
relation for signatures, while the old mono_class_signature_is_assignable_from_checked
preserves the existing behavior used elsewhere in the runtime.
* Check every method previously in the slot against the new impl
* UnitTest_GVM passes
* [metadata] Don't infinite loop in mono_class_get_flags for a FNPTR
When a MonoClass is a MONO_TYPE_FNPTR, the element_class is itself. We should
probably not do that, but meanwhile, make `mono_class_get_flags` return
something else for function pointer types.
Makes mono_class_is_interface not overflow the stack
* [metadata] Set MonoClass:cast_class for pointer types to the intermediate type
Ignore signedness differences and set cast_class to the storage type, same as
for arrays. This is used by mono_class_is_assignable_from when comparing
IntPtr* vs ulong*, for example.
* [metadata] Make mono_class_is_assignable_from work for unmanaged pointer types
The issue is that we need to compare intermediate type or the reduced type of
the element type, depending on whether we're doing compatability or general
assignment compatability (upshot: ulong* and long* are always inter-assignable,
but IntPtr* is not in signatures, but is for general storage)
* [metadata] Pull mono_type_byref_is_assignable_from out of ves_icall_RuntimeTypeHandle_type_is_assignable_from
Make it a separate internal function
* [metadata] mono_type_byref_is_assignable_from for valuetypes and class types should check for identity
X& and Y& where both are either a reference types or valuetypes are only
assignable if X and Y are identical. The old code was checking for identity
for valuetypes, but for reference types it would allow any two reference types
at all, which is incorrect.
* [class-init] Check for byref types in covariant return signatures
Lets us pass Loader/classloader/MethodImpl/CovariantReturns/UnitTest/CompatibleWithTest.il from the CoreCLR testsuite
* [interp] handle MONO_TYPE_FNPTR in mint_type
It's just a pointer-sized integer, as far as the interpreter's type discipline is concerned
* [class-init] Use a bit for covariant return method impls
Allows us to check implicit overrides against previous impl's sig when the previous impl potentially had a covariant return type.
Also use the bit to decide if we need to check signatures of the entire impl chain for explicit instantiations
* ReturnTypeValidation unit tests work on Mono now
* [class-init] check covariant vtable slots after overloads are applied
The check has to be done after both implicit and explicit overrides have been
applied because some implicit overrides must be ignored. If the check is done
as soon as we detect that a covariant return method override is needed, we will
incorrectly check implicit overrides that are to be ignored because a later
explicit override applied to the same slot.
* [metadata] Fix byref IsAssignableFrom
The reflection API has an interesting behavior, whereas the ECMA definition is
stricter.
```
public interface I {}
public class B {}
public class D : B, I {}
public struct S : I { }
class Program {
static void Main(string[] args)
{
var tb = typeof (B).MakeByRefType ();
var td = typeof (D).MakeByRefType ();
var ti = typeof (I).MakeByRefType ();
var ts = typeof (S).MakeByRefType ();
Console.WriteLine ($"{tb.FullName} is assignable from {td.FullName} ? {tb.IsAssignableFrom (td) }");
Console.WriteLine ($"{td.FullName} is assignable from {tb.FullName} ? {td.IsAssignableFrom (tb) }");
Console.WriteLine ($"{ti.FullName} is assignable from {td.FullName} ? {ti.IsAssignableFrom (td) }");
Console.WriteLine ($"{td.FullName} is assignable from {ti.FullName} ? {td.IsAssignableFrom (ti) }");
Console.WriteLine ($"{ti.FullName} is assignable from {ts.FullName} ? {ti.IsAssignableFrom (ts) }");
Console.WriteLine ($"{ts.FullName} is assignable from {ti.FullName} ? {ts.IsAssignableFrom (ti) }");
}
}
// Expected Output:
// B& is assignable from D& ? True
// D& is assignable from B& ? False
// I& is assignable from D& ? True
// D& is assignable from I& ? False
// I& is assignable from S& ? False
// S& is assignable from I& ? False
```
* rename mono_class_signature_is_assignable
No need for _checked suffix
* rename mono_byref_type_is_assignable_from
* [class-init] Move vtable setup to a separate file
The code is getting quite long, move it to a separate file
|
|
- Implementing QCalls on mono
- Use QCalls on ICU Shim implementation
Fixes https://github.com/dotnet/runtime/issues/36449
Co-authored-by: thaystg <thaystg@users.noreply.github.com>
|
|
* [mono] Move culture-info-tables.h to a separate directory
We'd like to remove culture-info-tables.h from the dotnet/runtime copy of mono since we use ICU
there for globalization like the rest of .NET 5.
The plan is:
1. We move the file (and some others) to a separate directory (this PR)
2. We tell the sync bot to skip `culture/` in the future
3. We delete the files (or make them empty) in dotnet/runtime
* Also move locale.c and culture-info.h
* Also move mono_w32process_ver_language_name
* [msvc] don't compile locales.c if it doesn't exist
It exists for now, but won't after we stop syncing culture/ to dotnet/runtime
|
|
Co-authored-by: lateralusX <lateralusX@users.noreply.github.com>
|
|
potentially shared between runtimes.
PR handling port of EventPipe C++ library from CoreCLR into a C library that can be shared between Mono as well as CoreCLR runtime.
Due to dependencies and current time line it has been decided to initially target Mono runtime (since it doesn't have event pipe functionality at the moment), but library is still designed to integrate into other runtimes, replacing current C++ library implementation, when time permits.
Until that happens, we will need to make sure changes done in C++ code base gets ported over to C library. The amount of changes going into the native library should however be small and if major changes needs to be done, we should first make sure to move over to use the shared version of event pipe C-library in CoreCLR and then only do changes into shared version of the library.
Port is currently mapping existing C++ code base, no focus on rewrite or change current implementation (unless needed to port code over to C).
Library source files are currently placed into mono/eventpipe folder and build as a separate library, linked into runtime, but will be moved when ready to be shared between runtimes. We might also move all code into a loadable library and p/invokes, depending on size, at least for Mono runtime targeting mobile devices.
There is also a unit test runner under mono/eventpipe/tests using eglib test runner, running through a set of unit tests covering the eventpipe library implementation.
Library is split up over a couple of source files closely mapping corresponding coreclr source files. Most code could be shared between runtimes and artifacts that are runtime specific, like locks/lists/maps/strings/pal layer etc, a shim API is defined in `ep-rt.h` and `ep-rt-types.h` that gets implemented by the targeted runtime consuming the event pipe C library, like `ep-rt-mono.h` and `ep-rt-types-mono.h`. All function in the shim API is small and should be inlinable. For example, locking the configuration lock is declared like this in `ep-rt.h`:
```
bool
ep_rt_config_aquire (void);
```
and in `ep-rt-mono.h` it is implemented like this:
```
static
inline
bool
ep_rt_config_aquire (void)
{
ep_rt_spin_lock_aquire (ep_rt_mono_config_lock_get ());
return true;
}
```
and CoreCLR should implement the function using its corresponding locking primitives. NOTE, since we primarily target Mono in initial port there might smaller adjustments needed to the shim API once bringing it over to CoreCLR, but those changes/adjustments can be done when needed.
Since library could be shared, it tries to standardize on common C99 data types when available. If there are runtime specific types needed, they are declared in `ep-rt-types.h` and implemented by each runtime in corresponding file. Most of library is currently following Mono coding guidelines.
For shared types naming is done like this, `EventPipe[Type]`, like `EventPipeProvider`. This naming follow naming of other types in Mono as well as CoreCLR. There is one exception to this rule, types that are runtime specific implementation, naming is following function naming with a _t prefix, like `ep_rt_session_provider_list_t`, that is a list specific type, implemented by each runtime. This is done to make it easier to see difference of types implemented in the runtime specific shim and types implemented in the shared library API surface.
Since library shim implemented by targeted runtime will be called by C code, it can't throw exceptions, the C library should however compile under C++, meaning that CoreCLR's shim should be able to use C++ constructions as long as it don't throw any exceptions.
Library function naming follows the following pattern, for "public" functions included in `ep-*.h` , ep_ + object + action, so for example, `ep_config_create_provider`, corresponds to `EventPipe::Configuration::CreateProvider` in C++ library. For "private/internal" functions not, ep_ prefix is dropped, but object + action is still preserved, for example `config_create_provider` and function is marked as being static when possible. If a function assumes a lock is held when getting called, it is using _lock_held (similar to SAL annotations) postfix to indicate that function doesn't claim lock and if function needs lock to be held by caller, it will assert that condition on enter (similar to `PRECONDITION(EventPipe::IsLockOwnedByCurrentThread())`).
Library uses asserts internally to validate state and conditions. This is a debug/checked build assert that should be excluded in release builds. It is defined in `EP_ASSERT` and should be redefined by targeted runtime. Private/internal functions asserts incorrect input parameters and state, while "public" functions return back error to caller when detecting incorrect input parameters. Incorrect state can still be assert in all kinds of functions.
Getters/Setters are setup for accessing type members. All functions except a type's own alloc/init/fini/free implemented in `ep-*.c` are not allowed to use direct type member access and should go through available inlinable getter/setter functions. There is also a way to build the library that catches incorrect use of members at compile time (not in `ep-*-internals.c` since it include alloc/init/fini/free implementations, but in other source files).
Types that can be stack allocated offers a init/fini function pairs. Types that should only be heap allocated, alloc/free, and types supporting both stack/heap, implements alloc/init/fini/free. Since C can't prevent incorrect usage patterns, the implementation needs to follow correct life time management patterns. Types allocated using alloc should be freed with corresponding free function. For example, `ep_event_alloc` should be freed by `ep_event_free`, the init/fini methods are then called by the alloc/free implementations. For types supporting stack allocation and allocated on stack or aggregated within other types, init must be called before first use and fini before going out of scope.
Ownership of allocated objects is only considered complete on successful function calls. If a function fails, caller still owns resource and need to take actions.
Library uses UTF8 strings internally, mainly since Mono runtime already uses that and it is more portable. Number of strings in the library is limited, and in cases where stream protocol uses UTF16 strings, a prealloc string is stored on the type, reducing need to do multiple UTF8 -> UTF16 conversions over the lifetime of the type.
NOTE, this is first PR setting up most of the direction of the library and (as part of doing that) ported a great deal of eventpipe code and added ~40 native unittests. It is however not complete, or fully working, so there will be several follow up PR's building on top of this work in order to get complete library. Next component to integrate into the library, once this PR is merged, is BufferManager.
|
|
Linking statically ICU shim on mono for windows, linux, macOs and android.
Co-authored-by: thaystg <thaystg@users.noreply.github.com>
|
|
CoreCLR static link vcruntime140.dll, but dynamic link rest of C-runtime using ucrt.lib in release build. Commit align Mono runtime to follow same pattern, removing dependency on vcruntime140.dll.
Co-authored-by: lateralusX <lateralusX@users.noreply.github.com>
|
|
We have functions that are de-facto part of the Mono embedding API that are
used by Xamarin.iOS or Xamarin.Android that are not in a state where we want to
commit to supporting them forever in their current form.
Nonetheless, we would like to make sure that the symbols for these functions
are visible even if we otherwise compile the runtime with
`-fvisisibility=hidden`, and we would like to discourage declaring the
functions in the embedder's own headers.
The functions that go into the
`mono/{utils,metadata,jit}/mono-private-unstable.h` headers will all be marked
with `MONO_API MONO_RT_EXTERNAL_ONLY` but we will not guarantee that the
functions will be there from one release to the next or that they will not
change their signatures or their behaviors.
Co-authored-by: lambdageek <lambdageek@users.noreply.github.com>
|
|
Fixes dotnet/runtime#2222
Co-authored-by: jkotas <jkotas@users.noreply.github.com>
|
|
Changes done in object-offsets.h adding offsets for TARGET_AMD64 exposed
a build configuration error in the Mono Tool MSVC debug build due to
incorrectly setting both X86 and AMD64 defines causing compile errors
when including object-offset.h. Release configuration didn't have this
configuration error, meaning that CI builds wouldn't trigger build error.
Fix makes sure all MSVC build configurations for Mono Tools
(genmdesc, monodis, pedump) matches the build configuration for other
binaries and that debug build configuration is inline with release build
configuration.
|
|
Subject to configuration, spawn has three widely divergent behaviors:
succeed but do nothing
print and exit
do what it sounds like
Rather than mislead the callers, provide only option 3 and let the caller decide what to do otherwise.
|
|
|
|
If LLVM build is done using different build configuration, Mono build
will fail to static link LLVM libraries due to incompatibility between
release and debug C++ runtime library, generating a lot of linker errors
like this:
error LNK2038: mismatch detected for 'RuntimeLibrary':
value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug'
in mini-llvm-cpp.obj
error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL':
value '0' doesn't match value '2' in mini-llvm-cpp.obj
This is normally not a problem when doing local builds of LLVM but
when using an external provided build, like netcore Mono build,
this problem is more likely to occur.
This fix adds an additional check to make sure build configuration reported
by llvm-config.exe --build-mode matches current Mono build configuration
and if not give a more specific msbuild error:
error : LLVM build Configuration=Release doesn't match current Mono
build Configuration=Debug
|
|
exist any more. (#18868)
* [llvm] Remove loaded llvm support, the startup perf penalty doesn't seem to exist any more.
* Fix the windows build.
* Remove more mini-llvm-loaded.c references.
* Remove more --enable-loadedllvm references.
* Make --enable-loadedllvm the same as --enable-llvm.
* Fix run-jenkins.sh.
* Address review comments.
|
|
Return address of local (deliberate).
Pointer cast to different size.
Function parameter and declaration badly mismatch (pid_t vs. void*).
Unused locals.
Top level volatile is ignored.
Negative shift undefined.
Call to undeclared function (getpid).
Some are fixed, some are disabled temporarily.
|
|
`CopyMonoRuntimeFilesFromArtifactsToDestination` target (#18797)
Fixes
```
fatal error C1083: Cannot open include file: '../../support/libm/complex.c': No such file or directory
```
when `mono-netcore.sln` is opened in vs2019
Also, add `CopyMonoRuntimeFilesFromArtifactsToDestination` target to mono.proj to be able to copy mono runtime bits to any folder (needed for the performance team, cc @fanyang-mono)
Co-authored-by: Egor Bogatov <egorbo@gmail.com>
|
|
Made minor fixes to the preload hook in the process.
The runtime will still crash if you don't specify the TPA paths and include corlib in that list, but it will at least hit an assert that makes clear it can't find corlib instead of attempting to dereference a null pointer in the preload hook.
The monovm header functions are exported for testing purposes, but the file is intentionally not made public as of now.
Co-authored-by: Ryan Lucia <ryan@luciaonline.net>
|
|
(#18559)
This change is motivated on two main fronts. The first is maintainability - the current managed implementation is difficult to understand and I worry diagnosing any potential issues would be a massive time sink. The second is performance - the current implementation appears to suffer from significant lock contention when running the TechEmpower plaintext benchmark. My hope is that the simpler, cleaner native implementation here will avoid both problems, but I don't want to merge it until we have benchmarking data. However, even if the numbers are similar, I still think it's worth merging just from a maintainability perspective.
The native LifoSemaphore implementation has only ever been tested on posix-like platforms, so Windows behavior is unknown. Currently the Windows implementation of LowLevelLifoSemaphore is very different, so unless we have need for the LifoSemaphore elsewhere in the runtime this isn't a concern.
Many thanks to @filipnavara for the initial implementation.
Co-authored-by: Ryan Lucia <ryan@luciaonline.net>
|
|
|
|
The default handlers for SIGTRAP, SIGSYS on macOS and Linux crash the process, so we now have Mono report this.
This patch also changes how the name of the signal is acquired for passing on to the crash reporting functions, allowing code reuse on crashing signals.
|
|
|
|
They need to be CRLF otherwise we'll get conflicts when moving into dotnet/runtime which has a .gitattributes setting forcing .bat to CRLF.
|
|
These can be easily replaced so we don't need to mirror over the mkinstalldirs file to the new repo
|
|
After https://github.com/mono/mono/pull/16832 was merged the run-msbuild.bat
script has an additional required parameter for specifying the GC.
However the script only passed the MONO_TARGET_GC property to msbuild
if the script had no additional parameters which doesn't make sense.
Always pass the parameter, this should fix the boehm build on Windows i386.
|
|
* Initial commit to migrate libgc to bdwgc.
* Fix submodule url
* Don't force Boehm as runtime wrapper. Was just for testing locally.
* Build bdwgc as single object file. Helps with performance.
* Bump bdwgc submodule.
* Attempt to fix windows MSVC based build.
* Remove any references to GC_INSIDE_DLL as we manually managed threads on Windows.
* Allow building boehm on Windows amd64.
* Allow building boehm with msvc.
* Bump bdwgc to fix line endings
* Use LF for sh, am, m4, and ac files in bdwgc
* Bump bdwgc & libatomic_ops with fix for cygwin
* Bump bdwgc to fix mono-boehm being generated as libtool wrapper script.
* Link the static boehm library.
* Revert "Link the static boehm library."
This reverts commit 1f90d81d08308a61c890743cd79d8f6bb791bc99.
* Use --export-all-symbols on cygwin/mingw to fix issues with boehm causing mono symbols not to be exported.
* Fix
|
|
This has the following benefits:
* Clearer structure for mirroring
* Slight build time improvement on bundled zlib use (as it only builds once)
* Removes pages of subdir-objects spew from autogen
|
|
|
|
|
|
Reduce the scope of git submodule update --init to only LLVM and/or BTLS
repositories when building external MSVC dependencies.
|
|
|
|
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.
|
|
* [runtime] Add a stub for MacOsIPInterfaceProperties::ParseRouteInfo icall on non-osx platforms to fix the wasm aot build.
* [wasm] Avoid generating invalid ninja build files if an assembly is specified on the command line and its also an implicit reference.
* Put back and ifdef.
* Fix the windows build.
|
|
when dumping (#17537)
* dump_native_stacktrace should always register the sigterm handler.
Cherry picked from the https://github.com/mono/mono/pull/17310
* [merp] Introduce a new 'dump mode' that allows different signal behavior when dumping
The primary reason for this is gaining the ability to interpret SIGTERM properly as a crashing signal when outside of 'dump mode', and as a utility signal during the 'thread summarizer' dumping process.
|
