[NativeAOT LLVM] Integrate dotnet.js into ILCompiler.LLVM #2453

maraf · 2023-12-07T13:53:45Z

Include dotnet.js in ILCompiler framework folder
- dotnet.js and dotnet.native.js built from typescript
- dotnet.es6.pre.js, dotnet.es6.lib.js and dotnet.es6.extpost.js emscripten partials & library
Remove emscripten build from wasm.proj and build it as part of naot-llvm build
Produce dotnet.js compatible app when DotNetJsApi=true is set in users app
- JS interop doesn't work yet
Changes to typescript
- Changes are driven by NativeAOT const for now. In follow ups we might come with a way to "override" functions different for NativeAOT
- Use emscripten's callMain at the moment
- Remove jiterpreter initialization
- Environment variables not supported at the moment
- Runtime options not supported
- Remove managed exports initialization
Add a smoke DotnetJs.csproj

pavelsavara · 2023-12-07T14:16:45Z

src/mono/wasm/runtime/es6/dotnet.es6.pre.js

@@ -2,5 +2,5 @@ if (_nativeModuleLoaded) throw new Error("Native module already loaded");
 _nativeModuleLoaded = true;
 // see https://github.com/emscripten-core/emscripten/issues/19832
 Module["getMemory"] = function () { return wasmMemory; }
-createDotnetRuntime = Module = createDotnetRuntime(Module);
+moduleArg = Module = moduleArg(Module);


Emscripten 3.1.47 generates

var createDotnetRuntime = (() => { var _scriptDir = import.meta.url; return ( async function(moduleArg = {}) {

I dunno yet if that can be configured somehow and I'm missing that flag or whether it's in empscripten (main has 3.1.34)

<_EmccLinkFlags Include="-s EXPORT_NAME="'createDotnetRuntime'"" />

maybe it's worth replacing the whole wasm.proj with latest from main ?

<_EmccLinkFlags Include="-s EXPORT_NAME="'createDotnetRuntime'"" />

I already have this one

runtimelab/src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

Line 112 in 1a55814

<_EmccLDFlags Include="-s EXPORT_NAME="'createDotnetRuntime'"" />

It produces the createDotnetRuntime, but the argument passed in is called moduleArg

Here is a sample dotnet.native.js that is generated by emcripten 3.1.47 dotnet.native.zip

hmmm, it seems we use createDotnetRuntime as default export in dotnet.d.ts but it seems it's a lie anyway.

src/mono/wasm/runtime/cwraps.ts

src/mono/wasm/runtime/invoke-cs.ts

src/mono/wasm/runtime/method-calls.ts

src/mono/wasm/runtime/run.ts

eng/pipelines/runtimelab.yml

SingleAccretion · 2023-12-08T12:23:11Z

A couple general questions, to start things off.

1) What is the general code flow (dependency graph) of the JS code? For example, here's the detailed graph for the current runtime:

Emscripten-generated code (host)
  [Emscripten ABI]
    Native entry point from bootstrapper.cpp
      <application code>
      [Emscripten ABI]
        pal_random.js; --js-library
        emscripten_get_callstack; Emscripten-provided system function

This needn't be as detailed, I am just looking for what the major components are, what their responsibilities are, and where they live (/how the functions they consist of are called).

2) What are the components in the build process of JS components? What is the build flow? How do you debug that build? Any common gotchas/known issues w.r.t. local development? We spend a very good chunk of our time fixing or altering the build in one way or another on this branch, so it's important to know how it works.

pavelsavara · 2023-12-08T12:25:59Z

    pal_random.js; --js-library

this doesn't exist anymore. It's moved into src\mono\wasm\runtime\crypto.ts

SingleAccretion · 2023-12-08T12:28:00Z

this doesn't exist anymore. It's moved into src\mono\wasm\runtime\crypto.ts

Yes; we restored it in this branch for the time being.

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Publish.targets

SingleAccretion · 2023-12-08T12:45:28Z

Add sample running main with dotnet.js

This should be added as a smoke test under src/tests/nativeaot/SmokeTests/HelloWasm.

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

SingleAccretion · 2023-12-08T14:46:38Z

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

+      <_EmccDefaultFlags Condition="'$(WasmEnableSIMD)' == 'true'">-msimd128</_EmccDefaultFlags>
+      <EmccStackSize Condition="'$(EmccStackSize)' == ''">5MB</EmccStackSize>
+      <EmccInitialHeapSize Condition="'$(EmccInitialHeapSize)' == '' and '$(_WasmCalculatedInitialHeapSize)' != '' and $(_WasmCalculatedInitialHeapSize) > 16777216">$(_WasmCalculatedInitialHeapSize)</EmccInitialHeapSize>
+      <EmccInitialHeapSize Condition="'$(EmccInitialHeapSize)' == ''">16777216</EmccInitialHeapSize>


There are a few things that already exist in our targets (e. g. we set the default stack size). Let's rationalize things as follows: there are "JS API" properties and "runtime" properties.

"JS API" properties apply to Browser + '$(DotNetJsApi)'=='true' only. They affect JS-specific things and/or expose emcc knobs. They should be used/defined here.

"Runtime" properties apply to both Browser and WASI. They will often affect core runtime semantics. They will be used/defined here:

runtimelab/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

Lines 504 to 563 in 6a2d69f

<ItemGroup>

<NativeLibrary Include="$(IlcFrameworkNativePath)libSystem.Native.a" />

<NativeLibrary Include="$(IlcFrameworkNativePath)libSystem.Globalization.Native.a" />

<NativeLibrary Condition="$(NativeLib) == '' and '$(CustomNativeMain)' != 'true'" Include="$(IlcSdkPath)libbootstrapper.o" />

<NativeLibrary Condition="$(NativeLib) != '' or '$(CustomNativeMain)' == 'true'" Include="$(IlcSdkPath)libbootstrapperdll.o" />

<NativeLibrary Include="$(IlcSdkPath)libPortableRuntime.a" />

<NativeLibrary Include="$(IlcSdkPath)libstandalonegc-disabled$(LibFileExt)" />

<NativeLibrary Condition="'$(IlcLlvmExceptionHandlingModel)' == 'cpp'" Include="$(IlcSdkPath)libCppExceptionHandling.a" />

<NativeLibrary Condition="'$(IlcLlvmExceptionHandlingModel)' == 'wasm'" Include="$(IlcSdkPath)libWasmExceptionHandling.a" />

<NativeLibrary Condition="'$(IlcLlvmExceptionHandlingModel)' == 'emulated'" Include="$(IlcSdkPath)libEmulatedExceptionHandling.a" />



<CustomLinkerArg Include="@(NativeLibrary->'"%(Identity)"'->Replace("\", "/"))" />

<CustomLinkerArg Include="@(NativeObjects->'"%(Identity)"'->Replace("\", "/"))" />

<CustomLinkerArg Include="-o "$(NativeBinary.Replace("\", "/"))"" />

<CustomLinkerArg Condition="'$(NativeDebugSymbols)' == 'true'" Include="-g3" />

<CustomLinkerArg Condition="'$(NativeDebugSymbols)' != 'true'" Include="-Wl,--strip-all" />

<CustomLinkerArg Condition="'$(NativeDebugSymbols)' != 'true'" Include="-Wl,--compress-relocations" />





<CustomLinkerArg Condition="'$(IlcLlvmTarget)' != ''" Include="-target $(IlcLlvmTarget)" />

<CustomLinkerArg Condition="'$(IlcLlvmExceptionHandlingModel)' == 'wasm'" Include="-fwasm-exceptions" />

</ItemGroup>

<ItemGroup Condition = "'$(_targetOS)' == 'browser'" >

<CustomLinkerArg Include="--js-library "$(IlcFrameworkNativePath)pal_random.lib.js"" />

<CustomLinkerArg Condition="'$(WasmHtmlTemplate)' != ''" Include="--shell-file "$(WasmHtmlTemplate)"" />

<CustomLinkerArg Condition="'$(ExportsFile)' != ''" Include="-s EXPORTED_FUNCTIONS=@"$(ExportsFile)"" />

<CustomLinkerArg Include="-s ALLOW_MEMORY_GROWTH=1" />

<CustomLinkerArg Include="-s ERROR_ON_UNDEFINED_SYMBOLS=0" />

<CustomLinkerArg Include="-s GLOBAL_BASE=$(IlcWasmGlobalBase)" />

<CustomLinkerArg Include="-s TOTAL_STACK=$(IlcWasmStackSize)" />

<CustomLinkerArg Condition="'$(WasmEnableJSBigIntIntegration)' == 'true'" Include="-s WASM_BIGINT=1" />

<CustomLinkerArg Condition="'$(IlcLlvmExceptionHandlingModel)' == 'cpp'" Include="-s DISABLE_EXCEPTION_CATCHING=0" />

</ItemGroup>



<ReadLinesFromFile File="$(ExportsFile)" Condition="'$(_targetOS)' == 'wasi' and '$(ExportsFile)' != ''">

<Output TaskParameter="Lines" ItemName="CustomLinkerArgExport" />

</ReadLinesFromFile>

<ItemGroup Condition ="'$(_targetOS)' == 'wasi'" >

<CustomLinkerArg Include="--sysroot="$(WASI_SDK_PATH.Replace("\", "/"))/share/wasi-sysroot"" />

<CustomLinkerArg Include="@(CustomLinkerArgExport->'-Wl,--export=%(Identity)')" />



<CustomLinkerArg Include="-Wl,--unresolved-symbols=ignore-all -Wl,--error-limit=0" />

<CustomLinkerArg Include="-lstdc++ -lwasi-emulated-process-clocks -lwasi-emulated-signal -lwasi-emulated-getpid" />

<CustomLinkerArg Include="-Wl,--max-memory=2147483648" />

<CustomLinkerArg Include="-Wl,--global-base=$(IlcWasmGlobalBase)" />

<CustomLinkerArg Include="-Wl,-z,stack-size=$(IlcWasmStackSize)" />

<CustomLinkerArg Include="-mexec-model=reactor" Condition="'$(NativeLib)' == 'Shared'" />

</ItemGroup>

<ItemGroup>

<CustomLinkerArg Include="@(LinkerArg)" />

</ItemGroup>

<WriteLinesToFile File="$(NativeIntermediateOutputPath)link.rsp" Lines="@(CustomLinkerArg)" Overwrite="true" Encoding="utf-8" />

<Exec Command="$(WasmLinkerPath) @$(NativeIntermediateOutputPath)link.rsp $(EmccExtraArgs)" EnvironmentVariables="@(EmscriptenEnvVars)" />

</Target>

(for now, we're planning to move them to a different file).

In this framework:

EmccStackSize is a "runtime" property. It should affect IlcWasmStackSize.

EmccInitialHeapSize - likewise.

WasmEnableSIMD is a no-op - we don't support SIMD yet - and so should be deleted.

I am also interested which of these MSBuild properties are documented. There should a clear separation between what is public (and cannot be changed), like WasmEnableSIMD, and what is not.

I will make a number of comments below about "runtime" properties. The way to fix them is to either: move the linker flag setting "down", or add an NYI comment instead, or just delete it because it's not a public property and we don't need to support all emcc flags by hand.

I'll move runtime properties as suggested
Removed WasmEnableSIMD

All public props are documented here https://github.com/dotnet/runtime/blob/e9ddf98c8502cfa00823dc94d3fcbfe5aa03ece7/src/mono/wasm/build/WasmApp.Common.targets#L6

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

pavelsavara · 2023-12-10T10:24:07Z

FYI dotnet/runtime#95775 we are refactoring those proj quite often.
I'm not sure that optimizing it here makes ton of sense from merging perspective.

SingleAccretion · 2023-12-10T10:44:05Z

I'm not sure that optimizing it here makes ton of sense from merging perspective.

Since we decided to keep a copy (of the compiler options-related MSBuild things), there is no conflict risk. There is still the problem of keeping the copy up-to-date, but it's the same whether we simplify it or not. And a number of these options have to be rewritten in any case.

SingleAccretion

A bit more feedback. Major point is the wasm.proj build. The earlier two questions still stand as well.

Thank you for adding the comments!

src/tests/nativeaot/SmokeTests/DotnetJs/Program.cs

src/tests/nativeaot/SmokeTests/DotnetJs/wwwroot/package.json

src/tests/nativeaot/SmokeTests/DotnetJs/wwwroot/main.js

src/tests/nativeaot/SmokeTests/DotnetJs/DotnetJs.csproj

SingleAccretion · 2023-12-13T13:51:37Z

src/tests/Common/scripts/nativeaottest.cmd

+if not exist %__JsFilePath% (
+  set __JsFilePath=%1\native\main.js
+)


I am a bit curious on the thinking about allowing project-specific output file names. It is non-standard for .NET projects for the output binary to not be named after the project itself.

It is non standard for .NET projects. On web it's up to the user how he names his entrypoint. Nothing settled IMO. Our templates has main.js as entrypoint.

I can rename main.js in the test to DotnetJs.js (as the project itself) if you prefer that

bike_shed.js 😉

No, it's fine to leave this as it is for now. I suppose it is not really the main file I am worried about, but the all of dotnet.* files. Ideally, the target there would be to have the same output as what Emscripten generates: one Project.js, one Project.wasm. It helps optics/perception. Nothing to do about that at this point, though.

We have multiple files for performance and modularity reasons. We are not going back to single JS file. It's more trouble than worth to live inside emscripten's JS postprocessing tooling. Also you need extra JS file for threads.

My perspective is "pay for play" design.

We also prefer that.

(e. g.: only link in JS string marshalling if something has a JSImport/JSExport with a string in it)

linker across C#/C/JS is though. Especially with JS being very dynamic.

In this specific example, we interpret the JS side of the "marshal single argument" from metadata about the method signature. And so we have to have all marshallers available on JS side.

Alternative is to ship generated JS code for each JSImport/JSExport. It has tooling and deployment troubles. Roslyn doesn't support that either.

We are not willing to try again. If you want to have look, see Net6 codebase we had.

Just curious - was it 'simply' that the code was ugly, or there was some more fundamental problem (too many Emscripten bugs, hard to track down failure modes, ...)?

In this specific example, we interpret the JS side of the "marshal single argument" from metadata about the method signature. And so we have to have all marshallers available on JS side.

Its possible to write it in such a way so as to make the dependencies explicit. For example, you can imagine that for:

[JSImport] void func(string);

The generator would generate:

[DllImport("*")] void js_marshal_string(); [JSImport, DependsOn("js_marshal_string")] void func(string); // Imaginary attribute; just for the sake of argument

That imaginary attribute would lead to passing --undefined:js_marshal_string to the linker, which would preserve that marshalling method in a C-like static linking scenario. Admittedly, this is questionable design, but good enough for illustrative purposes.

It is fine to say that "well, this is a rather complicated thing to do, so we will settle for some middle-of-the-road design, like making trimming based in feature switches and JS modules (one module per switch)", but then you really have to be careful with the amount of JS (hence my earlier point about avoiding it).

Alternative is to ship generated JS code for each JSImport/JSExport. It has tooling and deployment troubles. Roslyn doesn't support that either.

I'm dreaming about this one ❤️

Just curious - was it 'simply' that the code was ugly, or there was some more fundamental problem (too many Emscripten bugs, hard to track down failure modes, ...)?

Just go and have look :)

[DllImport("*")] void js_marshal_string();
[JSImport, DependsOn("js_marshal_string")] void func(string); // Imaginary attribute; just for the sake of argument

And to use that to fabricate roots for JS trimmer, right ?
JSExport could be more difficult.
Would that be multi-pass ?

It is fine to say that "well, this is a rather complicated thing to do, so we will settle for some middle-of-the-road design, like making trimming based in feature switches and JS modules (one module per switch)", but then you really have to be careful with the amount of JS

That's exactly where we are.

(hence my earlier point about avoiding it).

In that sense I agree, but not as top priority or goal on it's own.

And to use that to fabricate roots for JS trimmer, right ? JSExport could be more difficult.

Right. I haven't thought about this too deeply. On the surface, both imports and exports have similar requirements, "just" the direction of marshaling is reversed.

Would that be multi-pass ?

I don't immediately see why it needs to be.

src/mono/wasm/runtime/startup.ts

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

src/mono/wasm/runtime/loader/run.ts

src/tests/nativeaot/SmokeTests/DotnetJs/wwwroot/main.js

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>

maraf · 2023-12-13T16:43:37Z

What is the general code flow (dependency graph) of the JS code?

In browser case and the new smoke test concretely, it is

Browse opens index.html
User main.js script executes
- Imports dotnet.js which is public API for .NET
- Calls dotnet.create
  - Loads JS modules (dotnet.native.js and dotnet.runtime.js)
  - Loads WASM (dotnet.native.wasm)
  - Emscripten module starts
- Calls runMain
  - Emscripten's callMain executes

What are the components in the build process of JS components? What is the build flow? How do you debug that build? Any common gotchas/known issues w.r.t. local development? We spend a very good chunk of our time fixing or altering the build in one way or another on this branch, so it's important to know how it works.

Typescript is built using rollup. In debug build we get unminified version. In release they are minified. In both cases there are source maps pointing to original typescript definitions.

Does it answer the questions?

SingleAccretion · 2023-12-13T16:47:47Z

Does it answer the questions?

Yes, thank you.

src/mono/wasm/runtime/invoke-cs.ts

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets

src/mono/wasm/wasm.proj

SingleAccretion · 2023-12-13T18:35:42Z

src/tests/Common/scripts/nativeaottest.cmd

+if not exist %__JsFilePath% (
+  set __JsFilePath=%1\native\main.js
+)


And to use that to fabricate roots for JS trimmer, right ? JSExport could be more difficult.

Right. I haven't thought about this too deeply. On the surface, both imports and exports have similar requirements, "just" the direction of marshaling is reversed.

Would that be multi-pass ?

I don't immediately see why it needs to be.

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

eng/liveBuilds.targets

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

…et split

SingleAccretion

The changes LGTM. Thank you!

yowl · 2023-12-14T13:12:12Z

Very interesting, great work. Is it too early to add anything to the docs, like adding this to your project file if you want to use it

<DotNetJsApi>true</DotNetJsApi>

Are people going to think that [JSImport]/[JSExport] are supported with this change in NativeAOT-LLVM ?

maraf · 2023-12-14T13:33:35Z

Are people going to think that [JSImport]/[JSExport] are supported with this change in NativeAOT-LLVM ?

JS interop is tracked here #2434. I'll make it work as separated PRs. All that's working now is (synchronously) calling Main

Very interesting, great work. Is it too early to add anything to the docs, like adding this to your project file if you want to use it

I would wait a bit until there are more features working

maraf added 8 commits December 7, 2023 14:19

Fix typescript build

dd5e3bc

Build wasmruntime and include dotnet.js in framework

3c557bd

Include additional wasmruntime files in ILC framework

bdb6bd0

Remove all cwraps. use dotnet.js when DotNetJsApi=true

34462b4

Make it work (TM)

f420313

Extract DotNetJsApi link settings into a separate file

8e5a903

Fix merge

014bdcb

Remove emcc files from package

1a55814

maraf added the area-NativeAOT-LLVM LLVM generation for Native AOT compilation (including Web Assembly) label Dec 7, 2023

maraf requested review from pavelsavara and a team December 7, 2023 13:53

maraf self-assigned this Dec 7, 2023

pavelsavara reviewed Dec 7, 2023

View reviewed changes

maraf added 3 commits December 7, 2023 18:04

Revert invoke-cs.ts

c19a2d7

Ensure WasmObjDir

6a2d69f

Build wasm runtime for debug config

4affb5c

maraf commented Dec 8, 2023

View reviewed changes

eng/pipelines/runtimelab.yml Outdated Show resolved Hide resolved

SingleAccretion reviewed Dec 8, 2023

View reviewed changes

src/coreclr/nativeaot/BuildIntegration/DotNetJsApi.targets Show resolved Hide resolved

SingleAccretion reviewed Dec 8, 2023

View reviewed changes

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Publish.targets Outdated Show resolved Hide resolved

Add wasmruntime to clr.aot defaults

61a07da

SingleAccretion reviewed Dec 8, 2023

View reviewed changes

maraf added 3 commits December 9, 2023 20:00

Reduce EmscriptenEnvVars to default values

73d85cf

Remove _DefaultEmccFlags, no-limited-postlink-optimizations

e3bf8cb

Remove ReadEmccProps

4f6da2e

Fix result code

26adcea

SingleAccretion reviewed Dec 13, 2023

View reviewed changes

maraf and others added 4 commits December 13, 2023 16:08

Update src/tests/nativeaot/SmokeTests/DotnetJs/DotnetJs.csproj

cc6d39d

Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>

Check args. More straightforward exit code

eabddff

Revert import swap

4d4d1c4

Revert removed empty line

c766fbc

maraf added 5 commits December 13, 2023 18:22

Rewrite typescript changes as append only

d210293

Rewrite typescript changes as append only (2)

ecb3f03

Use CLRTestTargetUnsupported

247c6bb

Reuse _FilesToCopyToNative in publish

19431c9

Minimize changes to wasm.proj

9935515

maraf requested a review from SingleAccretion December 13, 2023 18:16

Guard mono_wasm_set_runtime_options for naot

1d32ee8

SingleAccretion reviewed Dec 13, 2023

View reviewed changes

maraf added 6 commits December 14, 2023 10:04

PrimaryRuntimeFlavor -> RuntimeFlavor

a105954

Revert unintended TS changes

f796292

Remove unused _WasmIntermediateOutputPath and _EmccLinkRsp

6597228

EmccInitialHeapSize only if not empty

934b85c

EmccStackSize to IlcWasmStackSize

30c0d98

Dont link pal_random.lib.js when dotnetjsapi. Revert LLVM linker targ…

d2a5528

…et split

maraf requested a review from SingleAccretion December 14, 2023 12:41

Revert whitespace

42b12fe

SingleAccretion approved these changes Dec 14, 2023

View reviewed changes

maraf merged commit 0641109 into dotnet:feature/NativeAOT-LLVM Dec 14, 2023

maraf deleted the dotnetjs branch December 14, 2023 14:03

yowl mentioned this pull request Mar 1, 2024

[NativeAOT-LLVM] [Question] Has upstream changed callMain for dotnet.native.js? #2523

Closed

	<ItemGroup>
	<NativeLibrary Include="$(IlcFrameworkNativePath)libSystem.Native.a" />
	<NativeLibrary Include="$(IlcFrameworkNativePath)libSystem.Globalization.Native.a" />
	<NativeLibrary Condition="$(NativeLib) == '' and '$(CustomNativeMain)' != 'true'" Include="$(IlcSdkPath)libbootstrapper.o" />
	<NativeLibrary Condition="$(NativeLib) != '' or '$(CustomNativeMain)' == 'true'" Include="$(IlcSdkPath)libbootstrapperdll.o" />
	<NativeLibrary Include="$(IlcSdkPath)libPortableRuntime.a" />
	<NativeLibrary Include="$(IlcSdkPath)libstandalonegc-disabled$(LibFileExt)" />
	<NativeLibrary Condition="'$(IlcLlvmExceptionHandlingModel)' == 'cpp'" Include="$(IlcSdkPath)libCppExceptionHandling.a" />
	<NativeLibrary Condition="'$(IlcLlvmExceptionHandlingModel)' == 'wasm'" Include="$(IlcSdkPath)libWasmExceptionHandling.a" />
	<NativeLibrary Condition="'$(IlcLlvmExceptionHandlingModel)' == 'emulated'" Include="$(IlcSdkPath)libEmulatedExceptionHandling.a" />

	<!-- wasi-sdk clang wants forward slashes, emscripten doesn't care -->
	<CustomLinkerArg Include="@(NativeLibrary->'"%(Identity)"'->Replace("\", "/"))" />
	<CustomLinkerArg Include="@(NativeObjects->'"%(Identity)"'->Replace("\", "/"))" />
	<CustomLinkerArg Include="-o "$(NativeBinary.Replace("\", "/"))"" />
	<CustomLinkerArg Condition="'$(NativeDebugSymbols)' == 'true'" Include="-g3" />
	<CustomLinkerArg Condition="'$(NativeDebugSymbols)' != 'true'" Include="-Wl,--strip-all" />
	<CustomLinkerArg Condition="'$(NativeDebugSymbols)' != 'true'" Include="-Wl,--compress-relocations" />
	<!-- see https://github.com/emscripten-core/emscripten/issues/16836 for the issue that means we have to force the linker to include these symbols before LTO -->
	<!--<CustomLinkerArg Condition="'$(Optimize)' != 'true'" Include="$(WasmOptimizationSetting) -flto" /> -->
	<CustomLinkerArg Condition="'$(IlcLlvmTarget)' != ''" Include="-target $(IlcLlvmTarget)" />
	<CustomLinkerArg Condition="'$(IlcLlvmExceptionHandlingModel)' == 'wasm'" Include="-fwasm-exceptions" />
	</ItemGroup>

	<ItemGroup Condition = "'$(_targetOS)' == 'browser'" >
	<CustomLinkerArg Include="--js-library "$(IlcFrameworkNativePath)pal_random.lib.js"" />
	<CustomLinkerArg Condition="'$(WasmHtmlTemplate)' != ''" Include="--shell-file "$(WasmHtmlTemplate)"" />
	<CustomLinkerArg Condition="'$(ExportsFile)' != ''" Include="-s EXPORTED_FUNCTIONS=@"$(ExportsFile)"" />
	<CustomLinkerArg Include="-s ALLOW_MEMORY_GROWTH=1" />
	<CustomLinkerArg Include="-s ERROR_ON_UNDEFINED_SYMBOLS=0" />
	<CustomLinkerArg Include="-s GLOBAL_BASE=$(IlcWasmGlobalBase)" />
	<CustomLinkerArg Include="-s TOTAL_STACK=$(IlcWasmStackSize)" />
	<CustomLinkerArg Condition="'$(WasmEnableJSBigIntIntegration)' == 'true'" Include="-s WASM_BIGINT=1" />
	<CustomLinkerArg Condition="'$(IlcLlvmExceptionHandlingModel)' == 'cpp'" Include="-s DISABLE_EXCEPTION_CATCHING=0" />
	</ItemGroup>

	<!-- wasm-ld only supports listing exports on the command line -->
	<ReadLinesFromFile File="$(ExportsFile)" Condition="'$(_targetOS)' == 'wasi' and '$(ExportsFile)' != ''">
	<Output TaskParameter="Lines" ItemName="CustomLinkerArgExport" />
	</ReadLinesFromFile>

	<ItemGroup Condition ="'$(_targetOS)' == 'wasi'" >
	<CustomLinkerArg Include="--sysroot="$(WASI_SDK_PATH.Replace("\", "/"))/share/wasi-sysroot"" />
	<CustomLinkerArg Include="@(CustomLinkerArgExport->'-Wl,--export=%(Identity)')" />
	<!-- Wasi has lots of undefined symbols currently, mostly globalization -->
	<CustomLinkerArg Include="-Wl,--unresolved-symbols=ignore-all -Wl,--error-limit=0" />
	<CustomLinkerArg Include="-lstdc++ -lwasi-emulated-process-clocks -lwasi-emulated-signal -lwasi-emulated-getpid" />
	<CustomLinkerArg Include="-Wl,--max-memory=2147483648" />
	<CustomLinkerArg Include="-Wl,--global-base=$(IlcWasmGlobalBase)" />
	<CustomLinkerArg Include="-Wl,-z,stack-size=$(IlcWasmStackSize)" />
	<CustomLinkerArg Include="-mexec-model=reactor" Condition="'$(NativeLib)' == 'Shared'" />
	</ItemGroup>

	<ItemGroup>
	<CustomLinkerArg Include="@(LinkerArg)" />
	</ItemGroup>

	<WriteLinesToFile File="$(NativeIntermediateOutputPath)link.rsp" Lines="@(CustomLinkerArg)" Overwrite="true" Encoding="utf-8" />
	<Exec Command="$(WasmLinkerPath) @$(NativeIntermediateOutputPath)link.rsp $(EmccExtraArgs)" EnvironmentVariables="@(EmscriptenEnvVars)" />
	</Target>

[NativeAOT LLVM] Integrate dotnet.js into ILCompiler.LLVM #2453

[NativeAOT LLVM] Integrate dotnet.js into ILCompiler.LLVM #2453

Uh oh!

Conversation

maraf commented Dec 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maraf Dec 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SingleAccretion commented Dec 8, 2023

Uh oh!

pavelsavara commented Dec 8, 2023

Uh oh!

SingleAccretion commented Dec 8, 2023

Uh oh!

Uh oh!

Uh oh!

SingleAccretion commented Dec 8, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SingleAccretion Dec 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pavelsavara commented Dec 10, 2023

Uh oh!

SingleAccretion commented Dec 10, 2023

Uh oh!

SingleAccretion left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SingleAccretion Dec 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

maraf commented Dec 7, 2023 •

edited

Loading

maraf Dec 7, 2023 •

edited

Loading

SingleAccretion Dec 8, 2023 •

edited

Loading

SingleAccretion Dec 13, 2023 •

edited

Loading

maraf Dec 13, 2023 •

edited

Loading