I think there needs to be two kind of tests 1. Tests that we get expected results when the correct FP is sampled 2. Tests that don't crash when wild FP's are sampled
For 1. the test with the code patch will provide a correct FP, and using a runtime function with a JavaScriptFrameIterator will reveal the exact same value. When the runtime system is entered the FP of the generated C entry frame is stored and so that will work both in release and debug mode. Another option to read FP is to add an inline runtime function. Inline runtime functions are by convention called _NAME, and have their code generated inline during code generation, see codegen.cc for CheckForInlineRuntimeCall. You could add a new function to the list, probably in an #ifdef/#endif (e.g. BUILDING_CCTEST) so it is only available for the cctests. Regarding the code patching this will actually break when the compiler improvements which are currently underway lands, as the generated code will be different. The patching could probably be changed to work again though. By the way using % functions requires FLAG_allow_natives_syntax to be set to true, but you can do that in the test, as a lot of the other cctests sets various flags. For 2. I suggest that having a test where a large number of different generated FP values are tried out and no crashing happens. In this mode I guess we might get fake stack traces which does not crash. Sorry about the comment on the the test being IA-32 specific I was not paying attention to the SConscript changes nor the actual file name. On Wed, Feb 25, 2009 at 2:16 PM, Mikhail Naganov <[email protected]>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
