Søren, I thought about introducing a function that obtains a frame pointer, but rejected this idea because I want to reproduce in tests situations that are similar to real life. In real life we have some function that is suspended (either due to signal or from another thread) and OS provides register values for it.
To my mind, we are mostly interested in "wild" situations in which current StackTraceIterator will crash. Otherwise, we would use it right now (ok, we must also change it to get FP not from Top, but from registers.) I've tried using the current StackTraceIterator---it mostly works, but crashes from time to time when running benchmarks scripts. So my plan is to establish "hard" cases in tests and implement a hardened version of stack iterators that don't crash (due to additional checks presumably.) Runtime function that captures EBP value (on IA32) isn't a solution because in the release mode, it simply will not work because of FPO. And if I will use JSFrameIterator instead of capturing EBP, then we will be imitating real life poorly. My patching relies on almost axiomatic facts that Smi's are represented using immediate values and that parameters are passed to runtime functions via stack, so it seems quite solid. On Wed, Feb 25, 2009 at 3:34 PM, <[email protected]> wrote: > Starting to add unit tests for the profiler is an excelent idea. However > I think you can simplify the tests, and make them platform independent. > The current approach only works your IA32, and having tests that works > on all (both) platforms is preferred. If this for some reason is not > possible there should be different .cc files like for test-assembler-*. > > Instead of using code patching to get the FP how about adding a runtime > function Runtime_GetFP to return the FP of the calling JS function like > Runtime_DebugPrint where the FP of the caller is printed? This could > then be called with %GetFP in the test function. > > On 2009/02/25 10:42:32, Mikhail Naganov wrote: > > > > > http://codereview.chromium.org/28112 > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
