Make dart build / dart compile exe / dart compile aot-snapshot produce code that can be profiled with native profilers

[mkustermann]

By default our AOT compiler (gen_snapshot) emits static symbols (that users can, if they want to, strip). Though that's not sufficient for native profiling tools to work properly:

• dart compile exe: We don't link the AOT compiled code statically into the binary, it's somewhat hidden as an inner ELF section, using our custom ELF loader. Making perf not be able to symbolize profiles
• dart compile aot-snapshot: We always produce ELF. That makes linux profiles with perf have symbols, but not on Mac / Windows
• dart build: Uses the above

The dart build must have (@dcharkes ?) logic to find assembler/compiler/linker installed on the system (as it passes paths to them to native asset build scripts). Could we use that and make the above tools by-default, if system-installed tools are available, produce dylib / .so / .dll files with symbols by using --snapshot-kind=app-aot-assembly and then producing the shared library?

If not by default, can we at least have a way for users to opt into the assembly behavior?

For context: See #54207

/cc @sstrickl @dcharkes

[dcharkes]

That would be lovely! I've always been compiling and running manually with --generate-perf-events-symbols to ensure I get both the Dart and C++ symbols.

The dart build must have (@dcharkes ?) logic to find assembler/compiler/linker installed on the system (as it passes paths to them to native asset build scripts).

No, only Flutter passes the assembler/compiler/linker. When invoking native asset builds from Dart, it's empty. The native_toolchain_c package used inside the build.dart script has the logic for discovering the native compiler.

Since native_toolchain_c is already being DEPSed into the SDK, we could opt to use it if it's available. But we should probably have a discussion on a product level whether we want to ship a C compiler of have a dart doctor that can tell you if you have a C compiler etc. cc @mit-mit

[fzyzcjy]

P.S. I am indeed using dart build because flutter_rust_bridge has some build.dart to compile the accompany Rust code. Thus though #54207 workaround works, I am looking forward to this feature!

[mkustermann]

Since native_toolchain_c is already being DEPSed into the SDK, we could opt to use it if it's available. But we should probably have a discussion on a product level whether we want to ship a C compiler of have a dart doctor that can tell you if you have a C compiler etc. cc @mit-mit

Well, it can transparently fallback to the current solution (ELF writer & ELF loader) if it's not available. It may be sufficient to check whether gcc or clang is available, try using it and if it fails falling back to current behavior. (possibly emitting a note about it)