Interesting, thanks for the update. Not sure what could cause that in fastcomp, but as it's deprecated anyhow at this point, probably best to focus on upstream.
On Thu, Jan 23, 2020 at 11:01 AM Brian Craft <[email protected]> wrote: > I just tried again with the llvm backend, and the stack traces look > correct. So, I doubt it's a chromium issue. More likely to be an emscripten > issue with fastcomp backend. > > > On Friday, January 17, 2020 at 2:13:49 PM UTC-8, Alon Zakai wrote: >> >> That first screenshot definitely looks wrong, yeah... weird. >> >> I'd try on latest (dev/canary), and if you still see that problem, please >> file a chromium bug. >> >> On Fri, Jan 17, 2020 at 6:01 AM Brian Craft <[email protected]> wrote: >> >>> _main doesn't call baos_push directly. Also, there isn't an inlining >>> scenario that would explain the stacktraces. Disabling inlining across >>> translation units doesn't affect the stacktraces. >>> >>> Attaching a couple screenshots. One is a single stacktrace, fully >>> expanded. The other is a bunch of other wasm functions, where you can see >>> they're all the same, and don't show any wasm->wasm calls. >>> >>> https://imgur.com/on5tkhw >>> >>> https://imgur.com/P0jenT6 >>> >>> On Thursday, January 16, 2020 at 7:20:42 AM UTC-8, Alon Zakai wrote: >>>> >>>> Those stack traces look like _main() (likely a JS wrapper) calls >>>> baos_push() or hfc_lookup(). Are those not correct stack traces? They do >>>> look a little odd as I'd expect to see main() (not a JS wrapper, but in >>>> wasm) in the middle, at least. >>>> >>>> If you were expecting more stack traces to be profiled, perhaps the >>>> random sampling didn't happen to pick any up because the sample was too >>>> short and those stack traces too rare? >>>> >>>> If you have a testcase you can share, I can take a look - I don't think >>>> I've seen something like this before, could be a bug. Or a screenshot might >>>> help too, maybe the UI is confusing (can try changing between top-down and >>>> bottom-up displays in the profiler perhaps, one might be less clear than >>>> the other). >>>> >>>> On Wed, Jan 15, 2020 at 2:36 PM Brian Craft <[email protected]> wrote: >>>> >>>>> When using the chrome profiler, the stack traces for wasm functions >>>>> are all identical. Like so: >>>>> >>>>> WASM_function#25:module:_baos_push >>>>> js-to-wasm#93:export:js-to-wasm#93 >>>>> Module._main >>>>> >>>>> WASM_function#101:module:_hfc_lookup >>>>> js-to-wasm#93:export:js-to-wasm#93 >>>>> Module._main >>>>> >>>>> Is this expected? What does it mean? To be clear, I was expecting the >>>>> stack to show the calls between the different wasm functions, as you would >>>>> see if profiling on other platforms. >>>>> >>>>> -- >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/c97ff1c3-0186-4b14-8685-6e9a30882677%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/c97ff1c3-0186-4b14-8685-6e9a30882677%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpT2K_%3DNsattcOGoH4BhQccQFicFWv8HxkEHHuYE8WXDAg%40mail.gmail.com.
