-
Hi, I am trying to profile an CPP application (compiled for WASM target) using gperftools heap profiler. I am able to compile the gperftools for WASM target and link it with the application with some changes but currently hit a roadblock with respect to backtrace logic. TL;DRStep 1. How can we get the address (PC) in the backtrace instead of text during profiling? gperftools internaly expects the backtrace to be presented in an array of addresses(pc's). But emscripten supports backtrace only in the text format. Is there a way to get the actual PCs(or some other format?) as a stacktrace during profiling time and then map these backtraces to human readable text format offline during analyze step. Thanks in advace. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
It might help to look at the internals of Emscripten's sanitizer support, which does work to convert stack traces to binary offsets. Relevant methods are emscripten_pc_get_function, emscripten_stack_snapshot and others in that area. In general, you can convert stack traces to binary offsets. For example, here is part of a stack trace in Node 16: at _fd_write (/home/azakai/Dev/emscripten/a.out.js:429:7)
at __wasi_fd_write (wasm://wasm/85545e82:wasm-function[2]:0x98)
at __stdio_write (wasm://wasm/85545e82:wasm-function[7]:0x57c)
at main (wasm://wasm/85545e82:wasm-function[5]:0x4fe) 429 is a line number in JS, and 0x98 is a binary offset in wasm. That is parsed by the stack trace handling code I mentioned before. |
Beta Was this translation helpful? Give feedback.
It might help to look at the internals of Emscripten's sanitizer support, which does work to convert stack traces to binary offsets. Relevant methods are emscripten_pc_get_function, emscripten_stack_snapshot and others in that area.
In general, you can convert stack traces to binary offsets. For example, here is part of a stack trace in Node 16:
429 is a line number in JS, and 0x98 is a binary offset in wasm. That is parsed by the stack t…