* [System.Drawing.Common] Work around libgdiplus use after free

On Windows, both of the following are legal

    Metafile mf = ... ; // get a metafile instance
    Graphics g = Graphics.FromImage(mf);
    g.Dispose(); mf.Dispose();

and

    Metafile mf = ... ; // get a metafile instance
    Graphics g = Graphics.FromImage(mf);
    mf.Dispose(); g.Dispose();

On Unix, libgdiplus has a use after free bug for the second form - the metafile
native image is disposed, but the graphics instance still has a pointer to the
memory that it will use during cleanup.  If the memory is reused, the graphics
instance will see garbage values and crash.

The workaround is to add a MetadataHolder class and to transfer responsibility
for disposing of the native image instance to it if the Metafile is disposed
before the Graphics.

Note that the following is not allowed (throws OutOfMemoryException on GDI+ on
Windows), so there's only ever one instance of Graphics associated with a
Metafile at a time.

    Graphics g = Graphics.FromImage(mf);
    Graphics g2 = Graphics.FromImage(mf); // throws

Addresses https://github.com/dotnet/runtime/issues/37838

* Formatting fixes
Co-authored-by: NSantiago Fernandez Madero <safern@microsoft.com>

* Address review feedback

* Inilne unhelpful helper

* formatting
Co-authored-by: NSantiago Fernandez Madero <safern@microsoft.com>

Port ComWrappers 5.0 diagnostic changes back to master and add stowed exception array to minidumps (#43164)

[master] Update dependencies from dotnet/arcade dotnet/runtime-assets dotnet/llvm-project dotnet/xharness dotnet/icu (#43084)

* Update dependencies from https://github.com/dotnet/arcade build 20200928.3

Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk , Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.XUnitExtensions , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.ApiCompat
 From Version 5.0.0-beta.20474.4 -> To Version 5.0.0-beta.20478.3

* Update dependencies from https://github.com/dotnet/runtime-assets build 20201005.2

System.ComponentModel.TypeConverter.TestData , System.Drawing.Common.TestData , System.IO.Compression.TestData , System.IO.Packaging.TestData , System.Net.TestData , System.Private.Runtime.UnicodeData , System.Runtime.TimeZoneData , System.Security.Cryptography.X509Certificates.TestData , System.Windows.Extensions.TestData
 From Version 5.0.0-beta.20476.1 -> To Version 5.0.0-beta.20505.2

* Update dependencies from https://github.com/dotnet/llvm-project build 20201005.1

runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools , runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools , runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk , runtime.osx.10.12-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools , runtime.osx.10.12-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk , runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools , runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk , runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
 From Version 9.0.1-alpha.1.20475.1 -> To Version 9.0.1-alpha.1.20505.1

* Update dependencies from https://github.com/dotnet/xharness build 20201005.1

Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Xunit
 From Version 1.0.0-prerelease.20502.4 -> To Version 1.0.0-prerelease.20505.1

* Update dependencies from https://github.com/dotnet/icu build 20201005.1

Microsoft.NETCore.Runtime.ICU.Transport
 From Version 6.0.0-alpha.1.20475.1 -> To Version 6.0.0-alpha.1.20505.1

* Don't downgrade Microsoft.DotNet.Helix.Sdk
Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: NAlexander Köplinger <alex.koeplinger@outlook.com>

Co-authored-by: NSantiago Fernandez Madero <safern@microsoft.com>
Co-authored-by: NJose Perez Rodriguez <joperezr@microsoft.com>

Co-authored-by: NGeoffrey Kizer <geoffrek@windows.microsoft.com>

* [wasm] Implement System.Console.Clear

* Add dummy console.clear implementation if it does not exist

* Initialize console in Clear

* Apply suggestions from codereview

* [test] Invoke from foreign threads then try to GC and shutdown

   Even if the non-Mono threads that once called Mono are looping or deadlocked,
   they shouldn't prevent us from doing a GC (in hybrid suspend mode) or from
   shutting down if they detached from the runtime.

* [tests] update .gitignore

   Ignore AOT build artifacts in subdirectories of mono/tests/, too

* [threads] Make mono_thread_attach external only

   Runtime should use mono_thread_internal_attach

* [threads] Mark mono_thread_detach external only; switch to GC Safe

   Runtime threads should call mono_thread_internal_detach

   Addresses https://github.com/mono/mono/issues/20290 and https://github.com/mono/mono/issues/20283

   If a foreign thread (that was created outside the runtime) calls
   mono_thread_detach, leave it in a preemptively-suspendable state, since we
   can't expect it to coop suspend.

   Conversely in mono_thread_attach (external only), ensure that we always leave
   the thread in GC Unsafe (aka RUNNING) state, for cases like
   
       while (cond) {
         t = mono_thread_attach (domain);
         <...>
         mono_thread_detach (t);
       }

* Tests fixup

   Delete test that invokes the runtime in a loop forever.
   This is just exercising a race between mono_thread_attach and the
   runtime shutdown.  Instead update the invoke_foreign_thread test to
   loop a few times to check that attach/detach loops are ok.

  In the deadlock test, wait for the foreign thread to finish calling
  the runtime before the test thread returns from native back to managed
   to avoid a race between shutdown and the invoke.


* [interp] Set context to null when freeing

   If a foreign thread runs this loop

       for (...) {
         mono_thread_attach;
         mono_runtime_invoke;
         mono_thread_detach;
      }

   on the second iteration it will get a ThreadContext that was already freed
   during the detach.  Set the TLS variable to null before freeing the context.


* [threads] Switch to GC Unsafe before creating managed thread object

   For a re-attaching move the thread state transition to happen earlier so that
   create_internal_thread_object (which does a managed allocation) is always done
   in GC Unsafe mode.


* fixup eventpipe to use mono_thread_internal_{attach,detach}
Co-authored-by: Nlambdageek <lambdageek@users.noreply.github.com>
Co-authored-by: NAleksey Kliger <alklig@microsoft.com>

* Fix ilasm managed resource lookup on Linux.

ILAsm did not properly find managed resources if they were not in the
working directory of ILAsm itself. While there was a provision for
Windows-based systems using backslashes as directory separators, there
was no such provision for *nix-based systems using forward slashes.

This commit enables ILAsm to lookup using both types of directory
separators.

* Use DIRECTORY_SEPARATOR_CHAR_A instead of hardcoded backslashes.

This fixes path handling on *nix targets.

* Only consider colon as a special path character on Windows.

This was only being done for OpenSSL 1.0. X509_new is actually available
to use in OpenSSL 1.0 and doesn't need to be re-defined:
https://www.openssl.org/docs/man1.0.2/man3/X509_new.html. That document
even says: "X509_new() and X509_free() are available in all versions of
SSLeay and OpenSSL".

The current libraries code doesn't contain an implementation of
local_X509_new. If we define X509_new as local_X509_new, it breaks the
build when it's being compiled non-portable against OpenSSL 1.0.

* Fixes Issue 42787

The GS COOKIE phase can create a new Basic Block and this will later cause an assert failure:
Assertion failed 'topBB->bbNum <= botBB->bbNum'
Previously this was hidden by an unconditional call to fgRenumberBlocks() which was removed in PR 42664

* Add a call to fgRenumberBlocks in the morphGlobalPhase when it creates new basic blocks

* Add CoreCLR compilation support for Apple Silicon
    * Use CMAKE_OSX_ARCH rework
    * Set clang -arch flag
    * Workaround uname arch reporting emulated arch

* Fix native code compilation issues
* Implement missing osx-arm64 functionality
* Prototype fix for write no execute issues
* Strip libunwind pointer authentication bits

* Review feedback
* Does not fix Arm64 ABI issues
Co-authored-by: NJan Vorlicek <janvorli@microsoft.com>

* upgrade to net6.0

* add comment and update package version

* address feedback and fix failures

* address feedbacl

* address feedback

In #2249, we started doing alignment of methods to 32-byte boundary for Tier1. However, a method having loops bypass tiering and hence this condition was never executed. Fixed it to make sure we do the alignment for optimized methods only and don't do it for prejitted methods.

* Allow enregistering more structs args

Allow HFAs and other structs with matching fields and registers.

Contributes to #37924

Expand usage of w32subset API partitioning making it possible to include/exclude/use/replace different subset of Win32 API's.

Merge UWP source files into regular Windows specific source files keeping one set of Windows implementation files in upstream repro leverage w32subset.h to support CLASSIC or UWP API subsets.

PR also extend capabilities to replace API usage using HAVE_EXTERN_DEFINED_WIN32* making it possible to exclude and replace API usage in downstream repositories.
Co-authored-by: NlateralusX <lateralusX@users.noreply.github.com>

* Console.Unix: reset terminal at exit in less cases to avoid blocking the parent.

When a parent is fetching the Console.Cursor position, it configures the terminal
to not echo, writes an escape sequence to query the position, and then reads the
position from stdin.

Because this doesn't happen atomically a child process can overwrite the terminal
settings to echo before the parent starts reading. This causes the position to
be echoed to the user, and the parent gets stuck waiting for input on stdin.

Currently terminal settings are reset at exit for applications that use the
Console or Process class. This change tracks whether the application has
changes the terminal settings and only then resets the terminal settings.

This doesn't fix the issue, but makes it less likely to occur.

* TermInfo changes are no longer needed

* Only configure terminal for child if we've touched the settings.

* minor change to comment wording

* add System.Net.Quic assembly and use it in HttpClient

* fix build issue

* remove old quic code from shared directory

* fix Common.Tests project

* fix WinHttp tests

* fix typo
Co-authored-by: NGeoffrey Kizer <geoffrek@windows.microsoft.com>

* Start stopwatch immediately before sending http request

* Remove extra line

* Remove trailing white space

* Introduce a concept of minimum array length into range check

* Some cleanup

* fix potential underflow

* bug fix and cleanup

* Revert string changes

* Allow elimination of arr[0] with  len != 0 test

* Revert "Revert string changes"

This reverts commit 6f77bf8c8acce1f5382bb704875384c6f8e2f984.

* Fix up tests

* reverting lower bound merging as it may be unsound

* Fix CI exposed bug and add a couple of test cases

* code review feedback

* comment nit

* feedback

* Add missing break

* Update function pointer syntax usage to official.

* Fix warnings with new Roslyn
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

* Clear the low bit of "Function Start RVA" on Arm Thumb2 machines in ReadyToRunMethod.cs

* Remove restrictions on InputArchitecture in ReadyToRunReader.cs and R2RDump.cs

RMW intrinsic operands doesn't have to be marked as "delay-free" when they can be assigned the same register as op1Reg (i.e. read-modify-write operand) and one of them is the last use.

One of the problems with BGC sweep is it zeros out the gen2 FL at the beginning which means we might need to increase gen2 size before it builds up enough FL to accommodate gen1 survivors. To lift this limitation I'm changing this to a doubly linked list so we can easily take items off and thread new ones back on.

Note that this is the initial checkin for the feature - there needs to be more stress testing and perf testing done on this so I'm checking in with the feature DOUBLY_LINKED_FL undefined. I've done some stress testing but not a whole lot.

This is only used for gen2 FL, not UOH - we already don't allow UOH allocations while we are sweeping UOH (which should be quite quick). In the future we will make it work so UOH allocs are allowed while it's being swept but that's beyond the scope of this feature (it would require work in the synchronization between the allocator and BGC sweep).

2 new bits were introduced -

Previously we didn't need to care about bgc mark bits at all since we can't possibly compact into the part of the heap that hasn't been swept. But now we can. So if we compact into a free item that hasn't been swept, we need to set the mark bits correctly. So we introduce a new bit:

// This bit indicates that we'll need to set the bgc mark bit for this object during an FGC.
// We only do this when we decide to compact.

Also now we don't have the luxury to allocate a min obj in the plan phase if what's allocated in this alloc context is too short. Previously we have this situation:

SB|MT|L|N

and if we plan allocated a min obj in this free item, we can allocate a min free obj right after it because the min free obj will not overwrite anything of that free item:

SB|MT|L|N
min free:
        SB|MT|Payload

since we don't touch SB. But now we have this:

SB|MT|L|N|P

and if we only allocated 3 ptr size into this free item, and if we want to allocate a min free obj, we'd be over writing P (previous pointer of this free item):

SB|MT|L|N |P
        SB|MT|Payload

One note on this is that we check the "allocated size" with (alloc_ptr - start_region), but start_region is updated every time we pad in the same free item. And it's really only necessary for the actual alloc context start (because we just need to preserve that free item's prev). But this is saved by the fact that in gen2 we don't pad. If we do pad in gen2 it would be good to handle this.

This is handled by set_free_obj_in_compact_bit (which sets the new MAKE_FREE_OBJ_IN_COMPACT bit) in adjust_limit where we set the bit and record the size of the "filler object". and we'll actually make the filler obj in gcmemcopy. This means this feature is as of now ONLY FOR 64-bit as the bit we use to do this means we are taking up 3 bits in MT to do our bookkeeping. We could make it work for 32-bit by finding bits in the gap - I haven't done that.

Major areas changed were -
+ allocate_in_older_generation - this also has a complication wrt repair and commit. I introduced the new added list concept so we can repair and commit quickly, with one exception for bucket 0. For b0 since we do discard items, we do need to set prev of discarded items to PREV_EMPTY because we need to indicate that it's not the freelist anymore. However, we can still recover by going through the original head and set the prev of the discarded items one by one which wouldn't be fast so I choose to not do it - the discarded items are generally very small anyway.

+ gcmemcopy - this needs to care about the bits we added.

+ background_sweep - this takes items off of the FL and thread new ones back on. Since this never happens at the same time as the gen1 GCs using these items we don't need synchronization here.

+ allocator class - obviously this needs to care about the prev field now. The principle is we don't touch the prev field in unlink_item (except for the special b0 case) so when we repair we don't need to go repair the prev fields. When we commit, we do need to set the new prev field accordingly (unless for the added list which we would have already set the prev correctly).

---

Fixed some existing bugs -

The refactor change stopped updating next_sweep_obj but it's incorrect because it's used by the verification code in sos so brought that back.

More accounting to count free_list/obj spaces correctly.

---

TODO

Optimizations we can do in background_sweep -

+ Don't need to actually take items off if we are just going to thread back on the same one (and others from my design notes);

+ If there's a big item we may not want to remove, imagine this simplied scenario - we have 1 2-mb free item on the list and we just removed it. Now current_num_objs happens to be big enough so we left an FGC happen and this FGC is gen1 and now it doesn't find any free space and would have to grow gen2.

It's actually beneficial to switch to using the added list even for singly linked list so we could consider enabling it even when the feature is not on.

- Fix last issue causing significant misbehavior in X86 Crossgen2 testing
  - Correctly report struct types in asCorInfoType for normalized structs
  - Previous efforts would not report the struct if it was normalized, where the correct behavior was to normalize, and report the struct if it isn't an enum

Around September 25 several dozens of Crossgen2 tests started
failing with a runtime error around incomplete instantiation of
GetArrayDataReference. I believe that for generic methods we
should skip the METHOD_ENTRY_DEF_TOKEN shortcut, otherwise we
lose the instantiation information and cause the runtime problem.

I originally thought this may be related to JanK's function
pointer changes but I no longer believe it is the case
(my apologies to Jan for the false accusation). I rather think
that some ambient code change caused a subtle difference in IL
encoding of access to the method that started tripping the
"shortcut" code path.

Thanks

Tomas

* Expose BackgroundService.ExecuteTask

Expose the task that executes the background service, so consumers can check if it is running and/or has ran to competition or faulted.

Use the new ExecuteTask to log exceptions when a BackgroundService fails after await, instead of appearing to hang.

Fix #35991
Fix #36017

Per https://github.com/dotnet/runtime/pull/43058#discussion_r499896492