Also add Call Frame Information (CFI) / Canonical Frame Address (CFA) directives.
This is required for native exceptions to work properly (otherwise the native runtime
won’t be able to unwind stack frames correctly).
There was a confusion between hex and decimal values, the values are written
using decimal in the headers, but were treated as hex values in the C# source.
This is a breaking change, but the values are just plain wrong, so I don't
really see a way around this. Also there's no good way to work around it by
accepting the old values and converting in our managed wrapper method, because
the old ARM values match the new PPC values, so there's no way to know if the
input is using old values or new values.
When using the MonoVM, we compare MonoClass instances by pointer. This turns
out a bit complicated for CoreCLR, because our MonoClass instances are not
unique (there can be multiple MonoClass instances that refer to the same
type), so instead implement helper methods that do the comparison. This also
has the benefit of not requiring any memory allocations on CoreCLR.
Adds a coherent parent dependency to `Microsoft.NET.ILLink.Tasks`, which
ensures that it will not be updated past the version included in
`Microsoft.Dotnet.Sdk.Internal`.
These changes allow us to remove our mono/linker darc subscriptions, as
`Microsoft.Dotnet.Sdk.Internal` updates will also bring in the latest
`Microsoft.NET.ILLink.Tasks` that the SDK references. This will reduce
the number of dependency update PRs created by maestro.
Since the `Microsoft.NET.ILLink.Tasks` and `Microsoft.NET.ILLink` NuGet
packages are created by the same build, we only need to track one of
these package IDs in eng/Version* files.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Enabling OneLocBuild to run every build we have on main because the Loc team will need the Loc artifacts to be published every time. By moving the conditional to the isPRSelected input, we will run the task every time but only create the PRs once a week!
The newly extracted `RegistrarRemovalTrackingStep` can be used inside
`dotnet-linker` to remove the dynamic registrar (if not required by some
other code).
We are using cascade pipelines, those are triggered automatically and
get all the artifacts. We create a json file that will be used by one of
the cascaded pipelines to make educated choices.
* [dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100
Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125
Context: https://github.com/xamarin/xamarin-android/pull/5898
The `$(PackageId)` of our workload `.nupkg` needs to be:
Microsoft.NET.Sdk._platform_.Manifest-6.0.100
While the `$(PackageVersion)` remains the same as before.
The layout on disk will change to:
dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk._platform_\
WorkloadManifest.json
WorkloadManifest.targets
Note that `.Manifest` and `-6.0.100` are not in the folder name on disk.
At the same time, let's also update the `version` in
`WorkloadManifest.json` so it contains the proper version for our
workload. This used to not be possible because `version` was a `long`,
but it now is a `string` where we can put our version.
* Use $(DOTNET6_VERSION_BAND)
* Pass in -p:VersionBand to 'dotnet pack'
This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS.
This should not change the original behavior when building from macOS.
The test was merge with the xammac_tests in commit
93bbfe7a86
but we did not have the tests running to know.
This should fix some of the failures we have in older macs.
- Make git ignore the generated `report.md`
- Fix `.aotdata` reported total size in reports (was always 0)
- Add option to strip the dotnet app bundle (until [1]) so it's easier to compare with _oldnet_ sizes.
[1] https://github.com/xamarin/xamarin-macios/issues/11445