Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable receiving and sending datagrams #1

Open
wants to merge 7,248 commits into
base: main
Choose a base branch
from
Open

Conversation

wegylexy
Copy link
Owner

No description provided.

@wegylexy wegylexy force-pushed the feature/msquic-datagram branch 7 times, most recently from b089239 to 3b0ca70 Compare February 26, 2021 18:44
@wegylexy
Copy link
Owner Author

Updated and tested with msquic 1.3.0 openssl on Linux and Windows. Note that 1.2.0 begins to work on Mac too.

@wegylexy wegylexy changed the base branch from master to main June 1, 2021 14:30
@wegylexy
Copy link
Owner Author

Rebased to resolve merge conflicts.

wegylexy pushed a commit that referenced this pull request Jul 19, 2021
…et#53792)

I have expanded the PerfMap format produced by Crossgen2 and
R2RDump to produce metadata in form of pseudo-symbol records with
high addresses. In this version I have implemented four metadata
entries - output GUID, target OS, target architecture and perfmap
format version number.  I have verified for System.Private.CoreLib
and for the composite framework that Crossgen2 and R2RDump
produce identical metadata.

To facilitate a smooth transition to the new perfmap format, in
accordance with Juan's suggestion I have introduced a new command-line
option to explicitly specify the perfmap format revision. As of today,
0 corresponds to the legacy Crossgen1-style output where the
perfmap file name includes the {MVID} section, perfmap format #1
corresponds to current Crossgen2 with its new naming scheme.
As of today there are no differences in the file content.

Thanks

Tomas
@wegylexy wegylexy force-pushed the feature/msquic-datagram branch 2 times, most recently from 49d4fb0 to 0746d48 Compare July 31, 2021 18:32
@wegylexy
Copy link
Owner Author

Rebased onto upstream main

wegylexy pushed a commit that referenced this pull request Feb 11, 2022
…otnet#63598)

* Fix native frame unwind in syscall on arm64 for VS4Mac crash report.

Add arm64 version of StepWithCompactNoEncoding for syscall leaf node wrappers that have compact encoding of 0.

Fix ReadCompactEncodingRegister so it actually decrements the addr.

Change StepWithCompactEncodingArm64 to match what MacOS libunwind does for framed and frameless stepping.

arm64 can have frames with the same SP (but different IPs). Increment SP for this condition so createdump's unwind
loop doesn't break out on the "SP not increasing" check and the frames are added to the thread frame list in the
correct order.

Add getting the unwind info for tail called functions like this:

__ZL14PROCEndProcessPvji:
   36630:       f6 57 bd a9     stp     x22, x21, [sp, #-48]!
   36634:       f4 4f 01 a9     stp     x20, x19, [sp, dotnet#16]
   36638:       fd 7b 02 a9     stp     x29, x30, [sp, dotnet#32]
   3663c:       fd 83 00 91     add     x29, sp, dotnet#32
...
   367ac:       e9 01 80 52     mov     w9, dotnet#15
   367b0:       7f 3e 02 71     cmp     w19, dotnet#143
   367b4:       20 01 88 1a     csel    w0, w9, w8, eq
   367b8:       2e 00 00 94     bl      _PROCAbort
_TerminateProcess:
-> 367bc:       22 00 80 52     mov     w2, #1
   367c0:       9c ff ff 17     b       __ZL14PROCEndProcessPvji

The IP (367bc) returns the (incorrect) frameless encoding with nothing on the stack (uses an incorrect LR to unwind). To fix this
get the unwind info for PC -1 which points to PROCEndProcess with the correct unwind info. This matches how lldb unwinds this frame.

Always address module segment to IP lookup list instead of checking the module regions.

Strip pointer authentication bits on PC/LR.
@wegylexy wegylexy force-pushed the feature/msquic-datagram branch 4 times, most recently from 0abea35 to df3b230 Compare February 16, 2022 03:44
eiriktsarpalis and others added 17 commits July 19, 2023 00:11
…net#89142)

mini_init_delegate () needs to do a reverse lookup from address
to method, and its possible for the address to be a static rgctx
trampoline if the address is the result of mono_ldftn ().

Fixes dotnet#89076.
…net#88892)

* [mono] Set the 'dynamic' flag on method builders on creation so a MonoDynamicMethod is allocated instead of a MonoMethodWrapper.

* [mono][interp] Fix memory leaks for interpreted dynamic methods.

* Add a mempool to MonoDynamicMethod.
* Modify the intepreter code to allocate from this mempool when
  interpreting dynamic methods.
dotnet#88723)

- Ship a single assembly for all platforms, and have better compatibility between our AOT engines
- Size of the shipped assembly for iOS-like platforms is increased by ~113Kb
- The fullAOT + UseInterpreter=true configurations with Mono are now interpreting Ref.Emit generated code instead of using Reflection
- To prevent size regressions with Mono xamarin/xamarin-macios#18555 needs to be merged
There were a couple things to fix

1) `PEReader` implements `IDisposable` and needs to be disposed.  Not least because it is managing the lifetime of the streams opened by `File.OpenRead` calls inside `ILVerifier`

2) In order to dispose of of the pereaders, add `IDisposable` to `ILVerifier` and add a `using` to the caller that creates a new instance.

(1) and (2) fix the issues with files being held open.

While looking at the code, I didn't see a reason why `TryLoadAssemblyFromFolder` couldn't check the `_assemblyCache` before creating a opening a new stream and creating a new pereader.  I don't think this was causing any issues.  It just seemed like a harmless just-in-case change.
We need access to this during our mark step.
…dCoreAsync (dotnet#89160)

* Avoid unnecessary closure in LoggingHttpMessageHandler.SendCoreAsync

* Remove unnecessary closure in LoggingScopeHttpMessageHandler.SendCoreAsync
The change from dotnet#88280 caused an issue when discovering the test:

```
System.InvalidOperationException : An appropriate member 'ManualTestsEnabled' could not be found. The conditional method needs to be a static method, property, or field on the type System.Formats.Tar.Tests.ManualTestsAsync or any ancestor, of any visibility, accepting zero arguments, and having a return type of Boolean.
```
* Fix broken runtime tests build (second attempt)

Continuation of dotnet#89115

* Update build-test-job.yml
…et#89177)

This fixes problem with posting results, where we crashed with:

    MONO_WASM:    at System.Text.Json.ThrowHelper.ThrowInvalidOperationException_JsonSerializerOptionsNoTypeInfoResolverSpecified()
       at System.Text.Json.JsonSerializerOptions.MakeReadOnly()
       at System.Text.Json.JsonSerializerOptions.ConfigureForJsonSerializer()
       at System.Text.Json.JsonSerializer.GetTypeInfo(JsonSerializerOptions , Type )
       at System.Text.Json.JsonSerializer.GetTypeInfo[JsonResultsData](JsonSerializerOptions )
       at System.Text.Json.JsonSerializer.Serialize[JsonResultsData](JsonResultsData , JsonSerializerOptions )
       at Sample.Test.GetJsonResults()
       at Sample.Test.GetFullJsonResults()
       at Sample.Test.__Wrapper_GetFullJsonResults_234275758(JSMarshalerArgument* __arguments_buffer)
    ManagedError@http://localhost:8781/_framework/dotnet.runtime.js:3:29628
    vr@http://localhost:8781/_framework/dotnet.runtime.js:3:34757
    Ao@http://localhost:8781/_framework/dotnet.runtime.js:3:52015
    To/U</<@http://localhost:8781/_framework/dotnet.runtime.js:3:50790
    init@http://localhost:8781/main.js:118:19
    setTimeout handler*yieldBench/<@http://localhost:8781/main.js:129:49
    yieldBench@http://localhost:8781/main.js:129:16
    init@http://localhost:8781/main.js:108:45
    setTimeout handler*yieldBench/<@http://localhost:8781/main.js:129:49
    yieldBench@http://localhost:8781/main.js:129:16
    init@http://localhost:8781/main.js:108:45
…B_REF (dotnet#89088)

Last-use copy omission allows the JIT to avoid creating copies of struct
values that are passed implicitly by-ref when the value is a last-use of
a local. When we do this we effectively address expose the
local for the lifetime of the call, so we mark the local as address
exposed as part of doing so.

However, there is a problem where morph may reorder two uses of a such a
local and break the last use information. For example, consider the
following case:

```
[000015] --CXG------      ▌  CALL      void   Program:Foo(int,int)
[000010] ----------- arg0 ├──▌  LCL_FLD   int    V00 loc0         [+0]
[000012] --CXG------ arg1 └──▌  CALL      int    Program:Bar(S):int
[000011] ----------- arg0    └──▌  LCL_VAR   struct<S, 32> V00 loc0          (last use)
```

V00 is used both at [000010] and at [000011], the latter as a last use.
Since we only address expose V00 when we get to [000011] we do not mark
[000010] with GTF_GLOB_REF; the net effect is the following call args
morphing, where we have reordered the two occurrences illegally:

```
[000015] --CXG+-----             ▌  CALL      void   Program:Foo(int,int)
[000037] DACXG------ arg1 setup  ├──▌  STORE_LCL_VAR int    V04 tmp3
[000012] --CXG+-----             │  └──▌  CALL      int    Program:Bar(S):int
[000011] -----+----- arg0 in rcx │     └──▌  LCL_ADDR  long   V00 loc0         [+0]
[000038] ----------- arg1 in rdx ├──▌  LCL_VAR   int    V04 tmp3
[000010] -----+----- arg0 in rcx └──▌  LCL_FLD   int   (AX) V00 loc0         [+0]
```

This change fixes the problem by running a separate pass over the IR
before morph to identify and address expose the candidates for last-use
copy omission. The net result is then the following correct IR:

```
[000015] --CXG+-----             ▌  CALL      void   Runtime_85611:Foo(int,int)
[000039] DA--G------ arg0 setup  ├──▌  STORE_LCL_VAR int    V05 tmp4
[000010] ----G+-----             │  └──▌  LCL_FLD   int   (AX) V00 loc0         [+0]
[000037] DACXG------ arg1 setup  ├──▌  STORE_LCL_VAR int    V04 tmp3
[000012] --CXG+-----             │  └──▌  CALL      int    Runtime_85611:Bar(Runtime_85611+S):int
[000011] ----G+----- arg0 in rcx │     └──▌  LCL_ADDR  long   V00 loc0         [+0]
[000038] ----------- arg1 in rdx ├──▌  LCL_VAR   int    V04 tmp3
[000040] ----------- arg0 in rcx └──▌  LCL_VAR   int    V05 tmp4
```

The pass has some TP impact but it is mitigated since we only need to
visit statements with GTF_CALL and since we can use the locals tree list
to prune which statements we visit.

Fix dotnet#85611
)

Use script for non-windows and powershell for windows.
Use the proper path separators for non-windows and windows.
* Update dependencies from https://github.com/dotnet/emsdk build 20230718.3

Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport
 From Version 8.0.0-preview.7.23367.1 -> To Version 8.0.0-rc.1.23368.3

* Compute the package name from the version

* Use a generated regex

* Use VersionBandForManifestPackages for CI/dev versions

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

Microsoft.NETCore.Runtime.ICU.Transport
 From Version 8.0.0-preview.7.23367.1 -> To Version 8.0.0-rc.1.23368.2

* Fix band calculation

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Larry Ewing <[email protected]>
jakobbotsch and others added 5 commits July 19, 2023 21:20
In release, code motion/compaction may lead to statements ending up in
blocks that don't contain their IL offset. This can cause splitting of
blocks to create meaningless IL ranges such as [057..020). Since we
maintain these IL ranges on a best-effort basis, just clamp them when we
do the splitting.

Fix dotnet#88348
* Remove `SetupLinkerKeepDebugMembersAttribute`.  This isn't supported anymore by the linker.

* Remove NETCOREAPP behavior difference in debugger attribute removal tests

* Move `DebuggerDisplayAttributeOnTypeWithNonExistentMethod` to the `KeepDebugMembers` folder since that is the scenario this test is testing
We implement our own `Driver.SetupContext`.  Our command line parsing logic is different and we have additional command line options.

In our very old revision of the upstream linker there was
```
protected LinkContext context;
```

Which we would set.  This would ensure that if one of the helper methods that uses the context were called that things would all work.
The most common scenario seems to be for error logging.  There are many helper methods that will call `Context.LogError` and if we haven't set the `context` field by then we have a problem.

We are syncing up and now the `context` field is private and there is a protected property getter, but no setter.

Adding a setter was the easiest way to get our context stored in the `context` field.
…9150)

* Share SourceWriter between JSON & config binding generators

* Fix failing test, clean up impl, and address feedback
The additional osx-x64 and osx-arm64 legs added for NativeAOT in dotnet#89018 caused the `runtime.osx-*.Microsoft.DotNet.ILCompiler` and runtime.osx-*.runtime.native.System.IO.Ports` packages to be duplicated.

This change makes sure we only publish them from one leg (the CoreCLR one).
@wegylexy wegylexy force-pushed the feature/msquic-datagram branch 5 times, most recently from 70c18c6 to 2cc7ce1 Compare July 20, 2023 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.