Open bruno-garcia opened 1 year ago
Just realized perhaps this belongs in dotnet/runtime
?
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
Author: | bruno-garcia |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `untriaged`, `area-VM-meta-mono` |
Milestone: | - |
/cc @maraf @pavelsavara - please triage this issue, and set milestone accordingly.
Note that the stack above is most likely C code of the MonoVM and it's interpreter. Looking at it's DWARF would not help you understanding the managed stack trace.
That's fair. I truncated off the C# code from the stack trace in this example. And it's true this was running in the interpreter. And I'm more interested in production environments so not really the interpreter. What I'm after is being able to map every frame back to something in its original form. App and "System" frames that is. I understand that might require going through DWARF for some native frames, and perhaps Portable PDB for some managed frames (at least to get line numbers in release builds, which we do already for normal .NET JIT workloads when users upload PDBs).
Is there LLVM/emcc support for the build_id
section already ?
Is there LLVM/emcc support for the
build_id
section already ?
I believe so: https://reviews.llvm.org/D107662
Hey, we're looking into improving the Blazor debugability. Is there any update on this?
It seems LLVM now has --build-id
flag.
@thaystg we should discuss what we can do
dotnet.wasm
binary with same id that we calculated during runtime buildmaybe WasmNativeBuildId
and we could also expose that ID on JavaScript runtimeBuildInfo
API
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Production stack traces are hard to debug:
Tools like Sentry support several debug file format. Including DWARF, PDB, Portable PDBs, etc. It also supports Wasm DWARF but it requires a way to identify the wasm modules at runtime. It has a JavaScript integration that patches things at runtime in order to collect the loaded modules. And with that it can load debug files when events come into the service.
Patching the
wasm
with a debug id after the fact breaks ASP.NET's ability to check for integrity, forcing the user to abandon it throughBlazorCacheBootResources
set tofalse
.Describe the solution you'd like
Attach a section called
debug_id
in the .NET wasm module :https://docs.sentry.io/platforms/native/guides/wasm/data-management/debug-files/identifiers/#wasm-build-ids
This way crash reporting tools can build integrations for Blazor to have better debuggability for production builds.
https://github.com/WebAssembly/tool-conventions/pull/183/files
Additional context
No response