Follow-up to https://github.com/dotnet/runtime/pull/43037#discussion_r499726268

We're installing openssl@1.1 from Homebrew so we should check that version.
It looks like CI Macs don't set the /usr/local/opt/openssl symlink anymore.

For newer Windows SDKs, the stdalign.h header is present, but the alignas macr is not
defined unless the compiler adds the std:c11 or newer.

Until we can set the std:c11 flag, work around the missing alignas macro using cmake config.

* accross -> across

* additionaly -> additionally

* adddress -> address

* addrees -> address

* addresss -> address

* aligment -> alignment

* Alignement -> Alignment

* alredy -> already

* argment -> argument

* Argumemnts -> Arguments

Co-authored-by: Nvargaz <vargaz@users.noreply.github.com>

* Reenable MUSL ARM tests

The packages for MUSL ARM should now be available, so reenable the
libraries tests in the CI

* Update DotnetHost and DotnetHostPolicy versions

* Add Linux arm musl to libraries queues

* Reenabling the arm32 queue in the coreclr templates queues

* Updated versions by darc tool, reverted libraries/helix-queues-setup.yml

With https://github.com/dotnet/xharness/pull/315 we can now make the test output similar to the regular xunit desktop runner.
It no longer prints the passed tests by default, only failing tests. To get the old behavior, add the `-v` flag back to xharness in tests.mobile.targets or check the new wasm-console.log file in the xharness-output folder.

```
  XHarness command issued: wasm test --app=. --engine=V8 --engine-arg=--stack-trace-limit=1000 --js-file=runtime.js --output-directory=/Users/alexander/dev/runtime/artifacts/bin/System.Runtime.Handles.Tests/net5.0-Release/browser-wasm/AppBundle/xharness-output -- --run WasmTestRunner.dll System.Runtime.Handles.Tests.dll -notrait category=OuterLoop -notrait category=failing
  info: 21:57:45.3244690 v8 --expose_wasm --stack-trace-limit=1000 runtime.js -- --run WasmTestRunner.dll System.Runtime.Handles.Tests.dll -notrait category=OuterLoop -notrait category=failing
  info: Arguments: --run,WasmTestRunner.dll,System.Runtime.Handles.Tests.dll,-notrait,category=OuterLoop,-notrait,category=failing
  info: console.debug: MONO_WASM: Initializing mono runtime
  info: console.debug: MONO_WASM: ICU data archive(s) loaded, disabling invariant mode
  info: console.debug: mono_wasm_runtime_ready fe00e07a-5519-4dfe-b35a-f867dbaf2e28
  info: Initializing.....
  info: Discovering: System.Runtime.Handles.Tests.dll (method display = ClassAndMethod, method display options = None)
  info: Discovered:  System.Runtime.Handles.Tests.dll (found 14 of 15 test cases)
  info: Starting:    System.Runtime.Handles.Tests.dll
  fail: [FAIL] SafeWaitHandleTests.SafeWaitHandle_False
  info: Assert.False() Failure
  info: Expected: False
  info: Actual:   True
  info:    at SafeWaitHandleTests.SafeWaitHandle_False()
  info:    at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
  info: Finished:    System.Runtime.Handles.Tests.dll
  info:
  info: === TEST EXECUTION SUMMARY ===
  info: Total: 14, Errors: 0, Failed: 1, Skipped: 0, Time: 0.097211s
  info:
  info: 21:57:46.3323620 Process exited with 1
```

library that can be shared between Mono as well as CoreCLR runtime.

Port follows same guidelines setup for event pipe port #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 how shim).

This is the first PR getting the code from diagnostic server codebase
over to C library.

* Throw PNSE on sync version of BrowserHttpHandler.Send

* Mark HttpClientHandler.Send as unsupported on browser

* Update reference source

* Optimize -X and MathF.Abs(X) for floats
Co-authored-by: NTanner Gooding <tagoo@outlook.com>

Add cross compilation testing for crossgen2.

The goal here is to cover cross compilation for the framework libraries, with support for testing cross compilation behavior between across the large swath of possible cross target possibilities.

This testing is added to the crossgen2 outerloop and is based on the work that @echesakovMSFT built for crossgen1 for cross target support for Linux X64 to Linux Arm. (The testing model has been tweaked to allow for general purpose cross target testing.)

Important details.

There is now a cross targeting build job, which builds (on either X64 Windows or X64 Linux) the framework dlls for a given target architecture, and captures their SHA1 hashes.

Then there is a comparison job which will run crossgen2 on an arbitrary set of platforms targetting a specific OS/Architecture pair. 

The current state is that is known that the x86 compiler does not quite produce identical output when varied between 64 and 32 bit, there are significant issues compiling arm32 code, and arm64 code is nearly perfect with cross compilation.

* Introduce THIRD-PARTY-NOTICES file for deployment with shared host package

* Update of THIRD-PARTY-NOTICES for .NET 5.0 release

* Update src/installer/pkg/THIRD-PARTY-NOTICES.TXT
Co-authored-by: NAdeel Mujahid <adeelbm@outlook.com>

* Update libunwind name in root TPN file to prevent regression in future updates

* Update libunwind license

* Updates based on review comments
Co-authored-by: NAdeel Mujahid <adeelbm@outlook.com>

When the Disassembler prints 4-byte and 8-byte values it should print them in little endian format

- used by two test projects

Fixes https://github.com/dotnet/runtime/issues/42917

Add two directories to NATIVE_DLL_SEARCH_DIRECTORIES to single-file bundles:

1. The bundle exe directory
2. If the bundle extracts any files, the extraction directory

Fixes #42772

* [wasm][crypto] RandomNumberGenerator mapped to Web Crypto getRandomValues

- Uses Web Crypto API [`getRandomValues`](https://www.w3.org/TR/WebCryptoAPI/#Crypto-method-getRandomValues) if available.
- Falls back to `/dev/urandom` as default if the crypto library is missing.

* Remove the emscripten interface code from the driver.c.

* remove extraneous code comment

* Move emscripten definition around.

* Address review comment

* Add javascript bridge implementation library to Native source tree.

- Javascript checks for crypto interface and uses `crypto.getRandomValues`
- Add api bridge call when building for emscripten browser.
- separate out into browser subdirectory
- If we couldn't find a proper implementation, as Math.random() is not suitable we will abort.

```

ABORT: no cryptographic support found getRandomValues. Consider polyfilling it if you want to use something insecure like Math.random(), e.g. put this in a --pre-js: var crypto = { getRandomValues: function(array) { for (var i = 0; i < array.length; i++) array[i] = (Math.random()*256)|0 } };

```

* Change tests to set random values of the buffer instead of return a single value.

* Remove old test code

* Remove testing code

* Incorporate the PAL bridge layer into the `--js-library` build process

* Address review comments about directory structure and naming

* Update src/mono/wasm/runtime-test.js
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>

* Add note about insecure code for testing purposes

* Formatting

* Return -1 if crypto does not exist instead of aborting from js.  This allows the managed code exception flow to continue as normal.
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>

* Add server core testing to Windows x64

* Add server core testing

* Use 20h1 queue instead

* Remove runtime testing until we get more capacity on 20H1 queue

* Use 2004 image

* Skip tests on Server core

* PR Feedback and fix build

* Disable more server core tests

* Disable more tests on Server Core

* Attempt fixing failing process test in server core

address feedback

* Fix PlatformDetection.IsInContainer for windows and feedback from Eirik's change

* PR Feedback

* Don't run server core on PRs yet until we get more capacity
Co-authored-by: NEirik Tsarpalis <eirik.tsarpalis@gmail.com>

* Add log for ILLinkSharedFramework target running in libraries build

* Address feedback -express that the operation is ongoing
Co-authored-by: NViktor Hofer <viktor.hofer@microsoft.com>
Co-authored-by: NViktor Hofer <viktor.hofer@microsoft.com>

* Create a SuperPMI collection pipeline

Start with a clone of jitstress.yml, and go from there.

* Only build Windows_NT_x64, disable test builds and runs

* TEMPORARY: disable normal PR triggered jobs

* some template files for superpmi

* Little trial error# 1

* fix the superpmi-setup.ps1

* Disable CoreClrTestBuildHost, fix the project path in superpmi-send-to-helix

* Skip build, download, create core_root

* Just copy superpmi scripts, import pipeline-logging-functions

* add a dummy step

* add missing space before message

* Replace message with script

* Temporarily disable dependsOn

* disable another dependsOn

* Pass superpmi.proj file

* logging around send-to-helix

* fix superpmi.proj to include ItemGroup

* have placeholder.txt in WorkItem folder

* fix workitem folder creation, script name

* Re-enable build coreclr, libraries, download, core_root

* fix superpmi.py path

* clone jitutils, build and copy pmi.dll

* Pass Core_Root as payload

* Use hardcoded checked

* Use .dotnet from runtime repo
- Build jitutils before and send the payload to helix

* Fix the pmi.dll location and add  -output_mch_path

* fix the output path

* Try publishing SourcesDirectory

* Upload to HELIX_WORKITEM_UPLOAD_ROOT

* Include test in collection and partition core_root and test

* Enable CoreClrTestBuildHost

* Add dependsOn P1 test

* Add DownloadFilesFromResults

* Properly copy the Tests

* Workaround for https://github.com/dotnet/arcade/pull/6179

* Disable test run, SuperPMI just system.web.dll

* Fix the mch path

* Comment partition for test

* Remove commented code

* Increase timeout to 12 hours

* fast pass

- Comment build coreclr/libraries job
- Instead just download coreclr from some previous run, and tell that it is core_root

* Update the machine pool

* Add a dummy step

* Use SuperPMI_Min.zip that contains all the required files

* Another way of Extracting cab

* download in powershell, extract files separately

* fix the zip path

* Another logic of download zip

* fix path

* fix newdir path

* more fixes

* fix extract step

* add test python script and modify creator

* Map secret to env

* decrease timeout, fix superpmi path in proj, print unzipped contents

* Add a step to download and dir artifacts

* Attempt to call super_pmi upload

* list all contents

* Also dir SourcesDir\artifacts

* Use DownloadPipelineArtifact

* Use the right key

* Upload from helixresults

* cleanup run-superpmi-job.yml

* Re-enable superpmi for CORE_ROOT

* fix the dependsOn

* Replace checked with $(BuildConfig)

* Replace checked with $(BuildConfig)
Comment download artifacts

* change helix queue for windows and add for arm64

* Use FileSeparateChar in superpmi.proj

* Add Linux x64

* Fix the helix queue, property erroro

* logging in shell

* Fix PayloadDir and CorrelationPayloadDir

* Make timeout to 5 hours

* Print workitem contents

* fix WorkItemDirectory

* Just copy pmi.dll

* fix the pmi_assemblies path

* disable reporter

* pop put JitUtilsDirectory before deleting it

* chmod for superpmi-setup.sh

* just copy pmi.dll for unix

* fix the parameter to unix

* Add logging to understand -pmi_assemblies issue

* Add "binaries" folder where payload is present
fix unit script that initializes array

* remove precommand

* Pass Core_Root as CorrelationPayload

- Pass Core_Root as CorrelationPayload
- Pass tag to name .mch file with
- Changes to .ps1 and .sh to copy Core_Root directly

* Add back the workaround for https://github.com/dotnet/arcade/pull/6179

Also, rename 'checked' -> 'Checked'

* fix checked for Linux

* mkdir for linux

* fix path in HelixResultsDestinationDir

* Enable Windows x86/arm64

* fix the python path

* First version of superpmi-setup.py

* Attempt to use superpmi-setup.py

* Fix spelling of LibrariesArtifacts, set python path

* TestArtifacts commented

* superpmi-setup script for linux

* Enable Linux_x64

* Added pydocs

* Add option for exclude_directories

* Moved all the logic to superpmi-setup.py

* Replace superpmi-setup.ps1 and superpmi-setup.sh with superpmi-setup.py

* Fix up in superpmi-setup.py

* fix display name

* add missing spacE

* Use differnet conditional

* ignore PermissionError while cleaning up temp folder

* fix workitem copy for linux

* fix copy for unix

* Publish logs

* Print LibrariesArtifacts

* remove space in front of publish logs desc

* Add missing quotes for LibrariesArtifacts

* Download x64 coreclr to make upload work

* Enable Windows x86/arm64, Linux arm/arm64

* Delete superpmi-setup.ps1, superpmi-setup.sh

* Fix space around LibrariesArtifacts

* Download real coreclr x64

* ignore native dlls

* Make superpmi.py Python3.6 friendly

* Minor cleanup

* Cleanup superpmi-send-to-helix to use helix-inner-step

* Remove redundant steps

* Merge mch files

* Pass osGroup

* Make superpmi-setup script takes tests_directory

* Enable SPMI collection for P1

* General cleanup

* fix merge_mch pattern for OS

* Log the SPMI collection output and put it in upload_root folder

* Replace robocopy/rsync with shutil.copy2

Note that shutil.copy2 is very slow specially on Linux as compared to rsync.
But I think we are ok to have slowness in return of simpler code.

* fix path of pmi.dll to be copied

* Include linux .so and file_exe files in copy_directories

* Try publishing just .mch file

* Revert "Try publishing just .mch file"

This reverts commit a5312c05f9502c7c2f2c5a28125f75f8d824b869.

* Disable tests SPMI collection on 42053

- Tests run times out on Windows
- Some of the partition's collection failed for tests because reply was not clean
- Here are the details when libraries/tests were run:
  https://dev.azure.com/dnceng/internal/_build/results?buildId=832814&view=results
- Hence, disable tests run and just have libraries run for now.
- I didn't remove the test run part but commented the portion of tests collection with
  TODO intentionally so when I have to enable it, I will know what to enable.

* Review feedback
Co-authored-by: NKunal Pathak <Kunal.Pathak@microsoft.com>

Fixes #40862
Co-authored-by: NStephen Toub <stoub@microsoft.com>
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>

* Fix HttpClient.CancelAllPending/Timeout handling for GetString/ByteArrayAsync

When GetStringAsync and GetByteArrayAsync are reading the response body, they're only paying attention to the provided CancellationToken; they're not paying attention to the HttpClient's CancelAllPending or Timeout.

* Address PR feedback

* make CancelConnectAsync thread safe

* replace var with MultipleConnectAsync

* Fix build errors on GCC.

* Enable PGO on Clang.

* Fix build errors on GCC 10 and later.

When packaging .NET for Linux distributions, the package builders
generally use a different workflow for shipping symbols to users:

1. The package maintainer builds code with the debug flags (such as
   `-g`) to generate full native debug info and symbols.

2. Nothing is stripped from build by the package maintainer.

3. The build system (`rpmbuild`, `debuild`) removes the debug
   info (or debug symbols) from the code and creates separate
   `-debuginfo` or `-debug` packages that contain just the debug
   symbols.

4. These debug packages are then distributed along with the normal
   packages using the normal Linux distribution mechanisms. This lets
   users install the exact set of debug symbols matching their other
   package.

To support this workflow in dotnet/runtime, we need to add optional
support for not stripping debug symbols. I used it has follows:

    CFLAGS=-g CXXFLAGS=-g ./build.sh --keepnativesymbols true

After this build, the built binaries include all debug symbols.

I can then rely on the distro package build system to identify, strip,
package and ship the debug info/symbols separately.

See https://github.com/dotnet/runtime/issues/3781 and
https://github.com/dotnet/source-build/issues/267 for more details on
the background and motivation.

For some related fixes, see:

- https://github.com/dotnet/coreclr/pull/3445
- https://github.com/dotnet/corefx/pull/24979