Alright, I took the plunge, and finally started fiddling with [`generateEnterJIT` in Trampoline-x64.cpp](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/src/jit/x64/Trampoline-x64.cpp#39). Thanks to all your comments (mostly comment 3 + tweaks) I managed to record the address of the "frame descriptor" into a new field in cx->activation_, and I can extract it and compare it to other available data... ([Code in Try](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=c76d185e00b7da766edf5017ac8d26426e3adb89), for the curious.) Wait a minute... "frame descriptor"? Other available data?? Is the work already done for me??? 🤔 If I read the code correctly, the info is mostly there: - In `generateEnterJIT`, there's [a frame description](https://searchfox.org/mozilla-central/source/js/src/jit/x64/Trampoline-x64.cpp#171) that helpfully indicates that this is a `CppToJSJit` frame, and the number of bytes in the frame, so it'd be possible to retrieve the previous stack frame pointer. - `JS::ProfilingFrameIterator` can go through all the frames, and in particular it gives us the "stackAddress", which is the return address that's pushed right after the frame descriptor! Glancing at the FrameIterator code, it seems possible that it could identify `CppToJSJit` frames (and I'm thinking that this could be stored in/near the [ProfilingFrameIterator::Frame::kind](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/public/ProfilingFrameIterator.h#112-113)), and extract the extra registers I would need to restart the stack walkers. `MergeStacks` iterates through all frames anyway, so I think it wouldn't add much work to find these important frames, and use them with the stop&start walkers. Before I go further into the woods, what do you experts think? TIA.
Bug 1635987 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Alright, I took the plunge, and finally started fiddling with [`generateEnterJIT` in Trampoline-x64.cpp](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/src/jit/x64/Trampoline-x64.cpp#39). Thanks to all your comments (mostly comment 3 + tweaks) I managed to record the address of the "frame descriptor" into a new field in cx->activation_, and I can extract it and compare it to other available data... ([Code in Try](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=c76d185e00b7da766edf5017ac8d26426e3adb89), for the curious.) Wait a minute... "frame descriptor"? Other available data?? Is the work already done for me??? 🤔 If I read the code correctly, the info is mostly there: - In `generateEnterJIT`, there's [a frame descriptor](https://searchfox.org/mozilla-central/source/js/src/jit/x64/Trampoline-x64.cpp#171) that helpfully indicates that this is a `CppToJSJit` frame, and the number of bytes in the frame, so it'd be possible to retrieve the previous stack frame pointer. - `JS::ProfilingFrameIterator` can go through all the frames, and in particular it gives us the "stackAddress", which is the return address that's pushed right after the frame descriptor! Glancing at the FrameIterator code, it seems possible that it could identify `CppToJSJit` frames (and I'm thinking that this could be stored in/near the [ProfilingFrameIterator::Frame::kind](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/public/ProfilingFrameIterator.h#112-113)), and extract the extra registers I would need to restart the stack walkers. `MergeStacks` iterates through all frames anyway, so I think it wouldn't add much work to find these important frames, and use them with the stop&start walkers. Before I go further into the woods, what do you experts think? TIA.
Alright, I took the plunge, and finally started fiddling with [`generateEnterJIT` in Trampoline-x64.cpp](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/src/jit/x64/Trampoline-x64.cpp#39). Thanks to all your comments (mostly comment 3 + tweaks) I managed to record the address of the "frame descriptor" into a new field in cx->activation_, and I can extract it and compare it to other available data... ([Code in Try](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=c76d185e00b7da766edf5017ac8d26426e3adb89), for the curious.) Wait a minute... "frame descriptor"? Other available data?? Is the work already done for me??? 🤔 If I read the code correctly, the info is mostly there: - In `generateEnterJIT`, there's [a frame descriptor](https://searchfox.org/mozilla-central/source/js/src/jit/x64/Trampoline-x64.cpp#171) that helpfully indicates that this is a `CppToJSJit` frame, and the number of bytes in the frame, so it'd be possible to retrieve the previous stack frame pointer. - `JS::ProfilingFrameIterator` can go through all the frames, and in particular it gives us the "stackAddress", which is where the return address is pushed right after the frame descriptor! Glancing at the FrameIterator code, it seems possible that it could identify `CppToJSJit` frames (and I'm thinking that this could be stored in/near the [ProfilingFrameIterator::Frame::kind](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/public/ProfilingFrameIterator.h#112-113)), and extract the extra registers I would need to restart the stack walkers. `MergeStacks` iterates through all frames anyway, so I think it wouldn't add much work to find these important frames, and use them with the stop&start walkers. Before I go further into the woods, what do you experts think? TIA.
Alright, I took the plunge, and finally started fiddling with [`generateEnterJIT` in Trampoline-x64.cpp](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/src/jit/x64/Trampoline-x64.cpp#39). Thanks to all your comments (mostly comment 3 + tweaks) I managed to record the address of the "frame descriptor" into a new field in cx->activation_, and I can extract it and compare it to other available data... ([Code in Try](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=c76d185e00b7da766edf5017ac8d26426e3adb89), for the curious.) Wait a minute... "frame descriptor"? Other available data?? Is the work already done for me??? 🤔 If I read the code correctly, the info is mostly there: - In `generateEnterJIT`, there's [a frame descriptor](https://searchfox.org/mozilla-central/source/js/src/jit/x64/Trampoline-x64.cpp#171) that helpfully indicates that this is a `CppToJSJit` frame, and the number of bytes in the frame, so it'd be possible to retrieve the previous stack frame pointer. - `JS::ProfilingFrameIterator` can go through all the frames, and in particular it gives us the "stackAddress", which is where the local return address is pushed right after the frame descriptor! Glancing at the FrameIterator code, it seems possible that it could identify `CppToJSJit` frames (and I'm thinking that this could be stored in/near the [ProfilingFrameIterator::Frame::kind](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/public/ProfilingFrameIterator.h#112-113)), and extract the extra registers I would need to restart the stack walkers. `MergeStacks` iterates through all frames anyway, so I think it wouldn't add much work to find these important frames, and use them with the stop&start walkers. Before I go further into the woods, what do you experts think? TIA.
Alright, I took the plunge, and finally started fiddling with [`generateEnterJIT` in Trampoline-x64.cpp](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/src/jit/x64/Trampoline-x64.cpp#39). Thanks to all your comments (mostly comment 3 + tweaks) I managed to record the address of the "frame descriptor" into a new field in cx->activation_, and I can extract it and compare it to other available data... ([Code in Try](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=c76d185e00b7da766edf5017ac8d26426e3adb89), for the curious.) Wait a minute... "frame descriptor"? Other available data?? Is the work already done for me??? 🤔 If I read the code correctly, the info is mostly there: - In `generateEnterJIT`, there's [a frame descriptor](https://searchfox.org/mozilla-central/source/js/src/jit/x64/Trampoline-x64.cpp#171) that helpfully indicates that this is a `CppToJSJit` frame, and the number of bytes in the frame, so it'd be possible to retrieve the previous stack frame pointer and the return address. - `JS::ProfilingFrameIterator` can go through all the frames, and in particular it gives us the "stackAddress", which is where the local return address is pushed right after the frame descriptor! Glancing at the FrameIterator code, it seems possible that it could identify `CppToJSJit` frames (and I'm thinking that this could be stored in/near the [ProfilingFrameIterator::Frame::kind](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/js/public/ProfilingFrameIterator.h#112-113)), and extract the extra registers I would need to restart the stack walkers. `MergeStacks` iterates through all frames anyway, so I think it wouldn't add much work to find these important frames, and use them with the stop&start walkers. Before I go further into the woods, what do you experts think? TIA.