Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[NativeAOT-LLVM] Add WasmExternalDwarf property to create an external_debug_info section#2786

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
yowl wants to merge6 commits intodotnet:feature/NativeAOT-LLVM
base:feature/NativeAOT-LLVM
Choose a base branch
Loading
fromyowl:dwarf3

Conversation

@yowl
Copy link
Contributor

This PR adds aWasmExternalDwarf build property,true by default forbrowser that will add aexternal_debug_info section and place the DWARF info a separate.debug.wasm file.wasmtime does not support this, at present, so only applies for the browser build.

@yowlyowl closed thisNov 19, 2024
@yowlyowl reopened thisNov 19, 2024
@yowlyowl marked this pull request as ready for reviewNovember 19, 2024 17:13
@yowl
Copy link
ContributorAuthor

Cc @dotnet/nativeaot-llvm

@pavelsavara
Copy link
Member

Do we need to do something to add the.debug.wasm file to the static assets ?
Do we want to do the same in upstream too ?

@jkotasjkotas added the area-NativeAOT-LLVMLLVM generation for Native AOT compilation (including Web Assembly) labelNov 19, 2024
@SingleAccretion
Copy link

Do we want to do the same in upstream too ?

It is a bit less pressing in upstream's case because the managed.pdbs are separate already and native debug info is off by default, but I think it would be a good feature to both enable that native debug info by default and use this option to have it not affect size.

However, I foresee this may be tricky in the upstream's case because of the names section. The names section is used by the engines to print out stack traces on traps (unhandled exceptions, asserts, ...). It would have to be tested whether the browsers out there are eager to download this sidecar file (that will contain the names section stripped from the main file) to print these stack traces. I suspect not.

In the NAOT's case this is not a big problem because we store the stack trace metadata directly in the executable, and are not super interested in native runtime stacks (since this 'native' part is small).

<IlcTreatWarningsAsErrorsCondition="'$(IlcTreatWarningsAsErrors)' == ''">$(TreatWarningsAsErrors)</IlcTreatWarningsAsErrors>
<_IsiOSLikePlatformCondition="'$(_targetOS)' == 'maccatalyst' or $(_targetOS.StartsWith('ios')) or $(_targetOS.StartsWith('tvos'))">true</_IsiOSLikePlatform>
<_IsApplePlatformCondition="'$(_targetOS)' == 'osx' or '$(_IsiOSLikePlatform)' == 'true'">true</_IsApplePlatform>
<WasmExternalDwarfCondition="'$(WasmExternalDwarf)' == ''and '$(_targetOS)' == 'browser' and '$(DotNetJsApi)' != 'true'">true</WasmExternalDwarf>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

There is already a documented property of this in the NAOT toolchain:StripSymbols. We can use it.

Also, why disable forDotNetJsApi? I think it makes sense forDotNetJsApi as well.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Probably, I didn't really know, and just copied what was in the publish file for the.wasm file. Will remove it.

Comment on lines 584 to 585

<CustomLinkerArgCondition="'$(WasmExternalDwarf)' == 'true'"Include="-gseparate-dwarf" />

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Suggested change
<CustomLinkerArgCondition="'$(WasmExternalDwarf)' == 'true'"Include="-gseparate-dwarf" />
<CustomLinkerArgCondition="'$(WasmExternalDwarf)' == 'true'"Include="-gseparate-dwarf" />

I think we should pass something likeGetFilenameWithoutExtension($(NativeBinary)).debug.wasm here to avoid the odd.wasm.debug.wasm thing.

yowl reacted with thumbs up emoji
Comment on lines 446 to 447
<WasmDwarfLinkerPathCondition="'$(EMSDK)' != ''">&quot;$(EMSDK)/upstream/bin/llvm-dwp$(ExeExt)&quot;</WasmDwarfLinkerPath>
<WasmDwarfLinkerPathCondition="'$(EMSDK)' == ''">&quot;$(EmscriptenSdkToolsPath)/bin/llvm-dwp$(ExeExt)&quot;</WasmDwarfLinkerPath>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks like leftovers from DWP (here and above withDwarfObjects).

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

thanks

Comment on lines 110 to 111
<DeleteFiles="$(PublishDir)\$(TargetName).debug.wasm"Condition="'$(_targetOS)' == 'browser' and '$(DotNetJsApi)' != 'true'"/>
<CopySourceFiles="$(NativeOutputPath)$(TargetName).debug.wasm"DestinationFolder="$(PublishDir)"Condition="'$(_targetOS)' == 'browser' and '$(DotNetJsApi)' != 'true'"/>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This should happen forDotNetJsApi as well and check whether the.debug.wasm file is present to copy, ideally using$(WasmSymbolFile).

<CustomLinkerArgInclude="-s TOTAL_STACK=$(IlcWasmStackSize)" />
<CustomLinkerArgCondition="'$(WasmEnableJSBigIntIntegration)' == 'true'"Include="-s WASM_BIGINT=1" />
<CustomLinkerArgCondition="'$(IlcLlvmExceptionHandlingModel)' == 'cpp'"Include="-s DISABLE_EXCEPTION_CATCHING=0" />
<CustomLinkerArgCondition="'$(StripSymbols)' == 'true'"Include="-gseparate-dwarf=&quot;$(WasmSymbolFile)&quot;" />
Copy link

@SingleAccretionSingleAccretionNov 21, 2024
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Hmm, does this embeds an absolute path, doesn't it. I think it would better to embed a relative path, i. e. just the file name. Otherwise I don't see it working even in our case where we copy from/native to/publish.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Actually, testing what this property does, this in fact the correct way to use it. Using an absolute path results in the relative path, and using a relative path result in something that is relative to the current working directory. Tricky but workable.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Not sure I follow the outcome of the comment here. It is ok as is? I think it was working when I tested it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It is ok as is?

Yes.

yowland others added3 commitsNovember 21, 2024 18:01
…e.targetsCo-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>
…e.targetsThanksCo-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>
Copy link

@SingleAccretionSingleAccretion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM, exciting to see this! Could you check that ourDotNetJs test is still debuggable, just in case?

@pavelsavarapavelsavara marked this pull request as draftFebruary 20, 2025 18:52
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@marafmarafAwaiting requested review from maraf

1 more reviewer

@SingleAccretionSingleAccretionSingleAccretion approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

area-NativeAOT-LLVMLLVM generation for Native AOT compilation (including Web Assembly)

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@yowl@pavelsavara@SingleAccretion@jkotas

[8]ページ先頭

©2009-2025 Movatter.jp