Fix determining of JS lower stack bottom used in profiler's JS stack tracer to work with Chromium.

Fix determining of JS lower stack bottom used in profiler's JS stack tracer to work with Chromium.

My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.

Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.

Committed: http://code.google.com/p/v8/source/detail?r=2086

[Mikhail Naganov, 2009-06-01 21:04:51]

Hi Kevin,

I would like you to look at this change to be sure that I'm not violating any
codegen-related rules.

[Søren Thygesen Gjesse, 2009-06-02 09:00:25]

LGTM

http://codereview.chromium.org/112082/diff/1/6
File src/top.h (right):

http://codereview.chromium.org/112082/diff/1/6#newcode88
Line 88: #define TOP_ADDRESS_LIST(C) \
How about making two lists TOP_ADDRESS_LIST_ALWAYS and
TOP_ADDRESS_LIST_PROFILING? See builtinsh.h and runtime.h where there is a
separate list for debugger related stuff (in runtime.h there is two _ALWAYS
lists due to Visual C++ choking on long macros).

[Mikhail Naganov, 2009-06-02 09:32:32]

Thanks, Søren!

http://codereview.chromium.org/112082/diff/1/6
File src/top.h (right):

http://codereview.chromium.org/112082/diff/1/6#newcode88
Line 88: #define TOP_ADDRESS_LIST(C) \
On 2009/06/02 09:00:25, Søren Gjesse wrote:
> How about making two lists TOP_ADDRESS_LIST_ALWAYS and
> TOP_ADDRESS_LIST_PROFILING? See builtinsh.h and runtime.h where there is a
> separate list for debugger related stuff (in runtime.h there is two _ALWAYS
> lists due to Visual C++ choking on long macros).

Good idea. Done.