| Age | Commit message (Collapse) | Author |
|---|
|
* [metadata] Size 0 Blob heap is ok when resolving assembly refs
Sometimes ILasm can produce images with a Blob heap of size 0. In cases where
we're loading assembly references from such an image, the hash (which is
optional) can be at index = 0 and the Blob heap size is also 0.
Also: add the hash value to the output of `monodis --assemblyref`
* [metadata] Add a separate assertion for the index == size == 0 case
And a comment explaining how it is likely to be triggered. If the assembly is
reasonable the caller of mono_metadata_blob_heap should be updated to use
mono_metadata_blob_heap_null_ok instead
* [bcl] Allow Mono's ILASM to produce a size 0 Blob heap
ECMA 335 II.24.2.4 says that the user string and blob heaps should have an
entry at index 0 consisting of the single byte 0. However .NET Framework (and
.NET Core) ilasm will entirely omit the Blob heap (that is, create a blob heap
entry of size 0) if it is not needed. This PR changes Mono's ILASM to emit the
initial byte on demand only if one of the MetaDataStream.Add() methods is
called. Otherwise we will also emit a stream of size 0.
This is needed to compile some test cases.
* [tests] Add regression test for loading assemblies with size 0 Blob heap
Depends on ILASM that can emit a size 0 Blob heap
|
|
This test https://github.com/dotnet/coreclr/blob/1649da12db73c8c07513c9168cb30ec70c310063/tests/src/Regressions/coreclr/20452/twopassvariance.il
On mono we were ordering the list of implemented interfaces and shouldn't do this as it's described on ECMA-335 Section II.12.2.1 and II.12.2.2.
The ordering was removed on ilasm and some changes were needed on metadata either because it's not ordered anymore.
There were two bugs, one on ilasm and other on class initialization on mono.
### ILAsm ###
If we get the .exe generated by .net Framework it doesn't execute on mono without modifications because we ordered the implemented interfaces list by id. And doing that the order defined on source code is ignored.
If we get the .exe generated by Mono it doesn't execute on .net Framework because on IlAsm we order the list and loose the order defined on source code.
The interfaces on metadata before these changes on IlAsm were like this:
```
1: Fooer1 implements class IFoo<class Derived>
2: Fooer1 implements class IFoo<class Base>
3: Fooer2 implements class IFoo<class Base>
4: Fooer2 implements class IFoo<class Derived>
5: Fooer3 implements class IFoo<object>
6: Fooer3 implements class IBar<class Derived>
7: Fooer3 implements class IBaz<class Base>
8: IBar implements class IFoo<!0>
9: IBaz implements class IFoo<!0>
10: Fooer4 implements IQux
11: Fooer4 implements class IBar<class Derived>
12: IQux implements class IFoo<class Base>
13: IQux implements class IFoo<class Derived>
14: Fooer5 implements IQux
15: Fooer5 implements class IBar<class Derived>
16: Fooer6 implements class IBar<class Base>
17: Fooer6 implements class IFoo<class Base>
18: Fooer7 implements class IFoo<class Base>
19: Fooer7 implements class IBar<class Base>
```
And After the changes they follow the definition order which is the same order of IlAsm for .net framework and .net core.
```
1: IBar implements class IFoo<!0>
2: IBaz implements class IFoo<!0>
3: IQux implements class IFoo<class Base>
4: IQux implements class IFoo<class Derived>
5: Fooer1 implements class IFoo<class Base>
6: Fooer1 implements class IFoo<class Derived>
7: Fooer2 implements class IFoo<class Derived>
8: Fooer2 implements class IFoo<class Base>
9: Fooer3 implements class IBaz<class Base>
10: Fooer3 implements class IBar<class Derived>
11: Fooer3 implements class IFoo<object>
12: Fooer4 implements IQux
13: Fooer4 implements class IBar<class Derived>
14: Fooer5 implements class IBar<class Derived>
15: Fooer5 implements IQux
16: Fooer6 implements class IFoo<class Base>
17: Fooer6 implements class IBar<class Base>
18: Fooer7 implements class IBar<class Base>
19: Fooer7 implements class IFoo<class Base>
```
### Mono vtable layout ###
Internally when Mono computes the interface table for each class, it would previously sort the interfaces by `MonoClass:interface_id` which is a unique id assigned (roughly) in load order. This was incorrect because the order of the interfaces determines the final vtable for the class. This PR changes the interface table computation so that the interfaces of a single class are ordered in declaration order, following ECMA.
One consequence is that we can no longer use binary search with the interface id as the key to find out if a class implements an interface. We have to do a linear scan. On the other hand, we expect that the number of interfaces implemented by a single class is small in practice.
This is how the Vtable for Fooer1 and Fooer2 looks like after the changes:
```
*** Vtable for class 'Fooer1' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fd78681db20]
[O][001][INDEX 001] object:GetHashCode () [0x7fd78681daf8]
[O][002][INDEX 002] object:Finalize () [0x7fd78681dad0]
[O][003][INDEX 003] object:Equals (object) [0x7fd78681daa8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fd786503800]
[I][005][INDEX 000] IFoo:Gimme () [0x7fd7865038c0]
Packed interface table for class Fooer1 has size 2
[000][UUID 078][SLOT 004][SIZE 001] interface IFoo[Base]
[001][UUID 079][SLOT 005][SIZE 001] interface IFoo[Derived]
```
and
```
*** Vtable for class 'Fooer2' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fd78681db20]
[O][001][INDEX 001] object:GetHashCode () [0x7fd78681daf8]
[O][002][INDEX 002] object:Finalize () [0x7fd78681dad0]
[O][003][INDEX 003] object:Equals (object) [0x7fd78681daa8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fd7865038c0]
[I][005][INDEX 000] IFoo:Gimme () [0x7fd786503800]
Packed interface table for class Fooer2 has size 2
[000][UUID 079][SLOT 004][SIZE 001] interface IFoo[Derived]
[001][UUID 078][SLOT 005][SIZE 001] interface IFoo[Base]
```
This is how the VTable for Fooer1 and Fooer2 looks like before the changes, as you can see Packed interface table are the same in Fooer1 and Fooer2, so the behavior of both classes was the same:
```
Vtable for class 'Fooer1' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fcf3801d920]
[O][001][INDEX 001] object:GetHashCode () [0x7fcf3801d8f8]
[O][002][INDEX 002] object:Finalize () [0x7fcf3801d8d0]
[O][003][INDEX 003] object:Equals (object) [0x7fcf3801d8a8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fcf37c29880]
[I][005][INDEX 000] IFoo:Gimme () [0x7fcf37c29940]
Packed interface table for class Fooer1 has size 2
[000][UUID 076][SLOT 004][SIZE 001] interface IFoo[Base]
[001][UUID 077][SLOT 005][SIZE 001] interface IFoo[Derived]
```
```
Vtable for class 'Fooer2' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fcf3801d920]
[O][001][INDEX 001] object:GetHashCode () [0x7fcf3801d8f8]
[O][002][INDEX 002] object:Finalize () [0x7fcf3801d8d0]
[O][003][INDEX 003] object:Equals (object) [0x7fcf3801d8a8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fcf37c29940]
[I][005][INDEX 000] IFoo:Gimme () [0x7fcf37c29880]
Packed interface table for class Fooer2 has size 2
[000][UUID 076][SLOT 005][SIZE 001] interface IFoo[Base]
[001][UUID 077][SLOT 004][SIZE 001] interface IFoo[Derived]
```
|
|
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.
|
|
|
|
* [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
|
|
override it (#10429)
* Move the PreBuild dependency property later in the file so targets can't override it
* [csproj] Update project files
|
|
* 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
|
|
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.
|
|
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
|
|
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
|
|
|
|
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.
|
|
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
|
|
* [msvc] Update csproj files
* [msvc] Delete old net_4_x.csproj and xbuild_12.csproj files
|
|
|
|
|
|
* [runtime] Allow access to protected default interface methods from classes which implement the interface.
* [interp] Add some automatic conversations between virtual and non-virtual calls that .net has. Fixes dim-valuetype.il.
* [bcl] Sort the MethodImpl table in PEAPI.
* [runtime] Enable dim-methodimpl.exe test.
* [runtime] Fix vtable construction tracing.
* [interp] Fix null checks on the receiver when converting virtual calls to non-virtual.
|
|
|
|
|
|
|
|
|
|
the AssemblyKeyFile attribute for consistency and to make it easier to do path name manipulation on the file name. (#5316)
|
|
|
|
|
|
|
|
|
|
|
|
The "cil" attribute seems to indicate that the data should be placed
in the .text section, along with the code.
Like the tls attribute, the cil attribute is only implemented insofar
as to recognize it as a valid keyword that can occur in a .data
declaration.
|
|
|
|
Note: DISABLE_CAS_USE was removed in ed989a8e9e5c170b6d19edc60bb80e8a4e6d5cc0
|
|
|
|
to appease MS msbuild
|
|
cyclic assemblies
|
|
|
|
* Adds support for a handful of new command line arguments that we now use in the build.
* Always attempts to match to a project name, to get the proper project dependency.
* Update to support .exe and .dll in the generation.
* Remove warnings and some dead code
* Update the resulting csproj files based on running:
make update-csproj
make package-inputs
mono genproj.exe
|
|
use full path.
One of csc prerequisites because csc uses -lib as path which is considered after
RuntimeEnvironment.GetRuntimeDirectory which makes -lib useless
|
|
CustomAttributeType and MemberRefParent.
This would cause some large il files to be miscompiled as the token size would not be the expected one.
This was found in b28158/test.il.
|
|
They weren't updated in the last 6 years and aren't helpful anymore (e.g. by causing unrelated matches during git grep searches).
|
|
We only use the net_4_x profile now so those csproj's don't make sense anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
reduce duplication.
|
|
variable which lists the assemblies a given assembly depends on to build.
|
|
|
