Support for return-address rewriting profilers.

src/platform-win32.cc

Index: src/platform-win32.cc
diff --git a/src/platform-win32.cc b/src/platform-win32.cc
index f16b5e74fda8705cd36db689eab1d2e94d0f0f17..8af41a0039a49990875ea634ece2b7ac6c963b2e 100644
--- a/src/platform-win32.cc
+++ b/src/platform-win32.cc
@@ -124,6 +124,19 @@ int random() {
 namespace v8 {
 namespace internal {
 
+typedef Address* (*ReturnAddressResolutionFunction)(Address*);
+static ReturnAddressResolutionFunction
+    LookupProfilerReturnAddressResolutionFunction() {
+  // DO NOT SUBMIT
+  // TODO(siggi): Check for the presence of the Syzygy instrumentation by

[Roger McFarlane (Chromium), 2012/02/15 21:19:03]

Another way to do this would be to introduce and reference a known symbol that
is set to NULL by default in the source code, but rewritten to point to the
imported resolution function during instrumentation.

That way less knowledge of the profiler is required here.

i.e.,
  // Declared non-const, at global scope, and marked extern.
  extern "C" ReturnAddressResolutionFunction address_resolution_func = NULL;

Usage below is then simplified:

  Address* OS::ResolveReturnAddressLocation(Address* pc_address) {
    if (address_resolution_func == NULL)
      return pc_address;
    return address_resolution_func(pc_address);
  }

It's the responsiblity of the instrumenter to recognize the symbol and rewrite
all references/relocs to it.

[Sigurður Ásgeirsson, 2012/02/15 21:45:56]

To expand on my email reply, the issue is that binary rewriting is so far
outside the ABI that results are totally unpredictable.
With WPO, the linker has sufficient information to know that nothing in the
binary refers to the pointer above, so the whole thing can and will be folded to
a noop.
As V8 is compiled by many users to in many different ways, and both to
executables and DLLs (as in the Chrome case), I hesitate to add mandatory
exports, especially a data export. There are all sorts of considerations that
come into play at that point. Even for a function export, it's not commonplace
to see those on EXEs, and the compiler/linker has freedom to duplicate
functions, so you could e.g. get a trivial inline at usage, in addition to an
export.
I feel binary rewriting by the instrumenter is not the way to go here.

+  //    testing for the presence of the .thunks segment. This is quick as
+  //    we're only looking at the image headers.
+  //    If instrumentation is present, look for the export we want on one of
+  //    the modules we import.
+  return NULL;
+}
+
+
 intptr_t OS::MaxVirtualMemory() {
   return 0;
 }
@@ -1241,6 +1254,31 @@ void OS::SignalCodeMovingGC() {
 }
 
 
+Address* OS::ResolveReturnAddressLocation(Address* pc_address) {
+  // Make the normal case where there is no profiling in effect very fast.
+  static bool no_profiling = false;
+  if (no_profiling)
+    return pc_address;
+
+  // Either profiling is in effect, or we haven't checked for the presence
+  // of the profiler yet.
+  static bool profiler_check_finished = false;
+  ReturnAddressResolutionFunction resolve_return_address = NULL;
+  if (!profiler_check_finished) {
+    resolve_return_address = LookupProfilerReturnAddressResolutionFunction();
+    profiler_check_finished = true;
+  }
+  ASSERT(profiler_check_finished);
+
+  if (resolve_return_address == NULL) {
+    no_profiling = true;
+    return pc_address;
+  }
+
+  return resolve_return_address(pc_address);
+}
+
+
 // Walk the stack using the facilities in dbghelp.dll and tlhelp32.dll
 
 // Switch off warning 4748 (/GS can not protect parameters and local variables