search

Haiyang-Sun / nodeprof.js

Instrumentation framework for Node.js compliant to ECMAScript 2020 based on GraalVM.
Apache License 2.0
53 stars 22 forks source link

No iid for builtin callbacks #43

Closed mwaldrich closed 5 years ago

mwaldrich commented 5 years ago

The builtinEnter and builtinExit callbacks don't provide any source location information. I guess this makes sense for builtinEnter, since there is no source location for the implementation of a builtin.

However, it would be very helpful to provide source location information on the builtinExit callback, as it is currently impossible to tell where a builtin in being invoked, from inside an analysis.

Haiyang-Sun commented 5 years ago

To get such kind of information, normally you need to maintain a invocation or call stack in your own analysis. We may be able to provide some util functions to give you the current JS call stack, but there is no information for the invocations.

alexjordan commented 5 years ago

I agree with @Haiyang-Sun, your analysis can derive the exact location of the call site (when it is in instrumented code) from the invokeFunPre callback.

mwaldrich commented 5 years ago

Ok, I think I understand. Both the invokeFunPre and builtin callbacks are issued when builtins are invoked from instrumented code. And when builtins are called from within other native code, they only issue builtin and not invokeFunPre. So every iid we could want will be given by the invokeFunPre callback?

Haiyang-Sun commented 5 years ago

A builtin can also be triggered without a callsite (e.g., some internal creation of Promise). Basically, you can always locate the builtin by tracking the nearest pre-post event pairs that enclose the builtin (e.g., you can track the start and end of statement or expression, and you would know which expression leads to the execution of a builtin).

mwaldrich commented 5 years ago

Got it, thanks for the clarification!