What is IsolateAddressId::kCEntryFPAddress for?

Thomson Tan

unread,

Jul 9, 2019, 4:21:09 AM7/9/19

to v8-users

Seems the JSEntry frame (Generate_JSEntryVariant) saves IsolateAddressId::kCEntryFPAddress from isolate. What is this C entry FP field for? I guess it saves frame pointer passed from C caller, but don't understand why it comes from isolate.

Jakob Kummerow

unread,

Jul 9, 2019, 5:09:20 AM7/9/19

to v8-users

The stack iterator needs to be able to skip over C++ frames on the stack. Information about the topmost C++ section is stored on the isolate (where else would you store it?), information about additional sections further down needs to be saved elsewhere. Storing it on the stack makes it easy for the stack walker to find it.

On Tue, Jul 9, 2019 at 10:21 AM Thomson Tan <lil...@gmail.com> wrote:

Seems the JSEntry frame (Generate_JSEntryVariant) saves IsolateAddressId::kCEntryFPAddress from isolate. What is this C entry FP field for? I guess it saves frame pointer passed from C caller, but don't understand why it comes from isolate.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/2cb3b405-4901-4c8a-90f5-9f684b29d4ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thomson Tan

unread,

Jul 9, 2019, 11:20:49 AM7/9/19

to v8-users

The stack iterator needs to be able to skip over C++ frames on the stack

Is this a general requirement for V8 generated code for all platforms? Use x64 for example which walks the stack by following frame pointer (rbp) chain, does this mean JS entry function should stop this frame pointer chain, and store the caller's frame pointer in isolate? How to usually handle the frame for JS entry function if a full stackwalk is needed?

On Tuesday, July 9, 2019 at 2:09:20 AM UTC-7, Jakob Kummerow wrote:

The stack iterator needs to be able to skip over C++ frames on the stack. Information about the topmost C++ section is stored on the isolate (where else would you store it?), information about additional sections further down needs to be saved elsewhere. Storing it on the stack makes it easy for the stack walker to find it.

On Tue, Jul 9, 2019 at 10:21 AM Thomson Tan <lil...@gmail.com> wrote:

Seems the JSEntry frame (Generate_JSEntryVariant) saves IsolateAddressId::kCEntryFPAddress from isolate. What is this C entry FP field for? I guess it saves frame pointer passed from C caller, but don't understand why it comes from isolate.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

Jakob Kummerow

unread,

Jul 9, 2019, 11:52:34 AM7/9/19

to v8-users

On Tue, Jul 9, 2019 at 5:20 PM Thomson Tan <lil...@gmail.com> wrote:

The stack iterator needs to be able to skip over C++ frames on the stack
Is this a general requirement for V8 generated code for all platforms?

Yes.

Use x64 for example which walks the stack by following frame pointer (rbp) chain, does this mean JS entry function should stop this frame pointer chain, and store the caller's frame pointer in isolate?

The other way round. The caller of JSEntry is a C++ function, and we make no assumptions about the stack layout that the C++ compiler generates for those. The JSEntry stub creates a new chain of rbp pointers (throughout the following invocations of generated code). It stores the last C entry frame position, so when walking the stack in the other direction, the stack walker can jump from the JSEntry frame to the previous CEntry frame (if there is one).

How to usually handle the frame for JS entry function if a full stackwalk is needed?

See class EntryFrame in frames.h, in particular EntryFrame::GetCallerState, and compare it with what Generate_JSEntryVariant in builtins-x64.cc does.

Thomson Tan

unread,

Jul 9, 2019, 1:32:31 PM7/9/19

to v8-users

Thanks a lot for the details. For a single isolate, how is the case for multiple nested JSEntry and CEntry handled?

For EntryFrame::GetCallerState, seems it requires to use stack walker provided by V8, like JavaScriptFrameIterator. How does it work for other stackwalker which cannot invoke V8 code directly, for example, stack walk in postmortem dump file and ETW?

Jakob Kummerow

unread,

Jul 9, 2019, 2:18:41 PM7/9/19

to v8-users

On Tue, Jul 9, 2019 at 7:32 PM Thomson Tan <lil...@gmail.com> wrote:

Thanks a lot for the details. For a single isolate, how is the case for multiple nested JSEntry and CEntry handled?

Stack frames by definition form a sequence, there is no way to nest them. Ranges of C++ frames are bounded by a CEntry frame on one side and a JSEntry from the other, that's how the stack walker can skip over them.

For EntryFrame::GetCallerState, seems it requires to use stack walker provided by V8, like JavaScriptFrameIterator. How does it work for other stackwalker which cannot invoke V8 code directly, for example, stack walk in postmortem dump file and ETW?

I don't know.

On Tuesday, July 9, 2019 at 8:52:34 AM UTC-7, Jakob Kummerow wrote:
On Tue, Jul 9, 2019 at 5:20 PM Thomson Tan <lil...@gmail.com> wrote:
The stack iterator needs to be able to skip over C++ frames on the stack
Is this a general requirement for V8 generated code for all platforms?

Yes.

Use x64 for example which walks the stack by following frame pointer (rbp) chain, does this mean JS entry function should stop this frame pointer chain, and store the caller's frame pointer in isolate?

The other way round. The caller of JSEntry is a C++ function, and we make no assumptions about the stack layout that the C++ compiler generates for those. The JSEntry stub creates a new chain of rbp pointers (throughout the following invocations of generated code). It stores the last C entry frame position, so when walking the stack in the other direction, the stack walker can jump from the JSEntry frame to the previous CEntry frame (if there is one).

How to usually handle the frame for JS entry function if a full stackwalk is needed?

See class EntryFrame in frames.h, in particular EntryFrame::GetCallerState, and compare it with what Generate_JSEntryVariant in builtins-x64.cc does.

On Tuesday, July 9, 2019 at 2:09:20 AM UTC-7, Jakob Kummerow wrote:
The stack iterator needs to be able to skip over C++ frames on the stack. Information about the topmost C++ section is stored on the isolate (where else would you store it?), information about additional sections further down needs to be saved elsewhere. Storing it on the stack makes it easy for the stack walker to find it.

On Tue, Jul 9, 2019 at 10:21 AM Thomson Tan <lil...@gmail.com> wrote:
Seems the JSEntry frame (Generate_JSEntryVariant) saves IsolateAddressId::kCEntryFPAddress from isolate. What is this C entry FP field for? I guess it saves frame pointer passed from C caller, but don't understand why it comes from isolate.

--

--

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/5b35aac3-dd64-4cb9-a54d-f29df130c364%40googlegroups.com.

Reply all

Reply to author

Forward