Fix the problem with JS entries in tickprocessor.

The main problem was due to the following: after Erik had fixed the logger to report library addresses, tickprocessor started to add to the code map entries that covered almost entire memory. This happened because tickprocessor contains a heuristic to bias addresses of functions from dynamic libraries:

    if (funcInfo.start < libStart && funcInfo.start < libEnd - libStart) {
      funcInfo.start += libStart;
    }

And, as tickprocessor tried to process all symbols from the library, including data entries, which can be outside reported library addresses range, the second condition failed, and funcInfo.start remained unbiased.

Review URL: http://codereview.chromium.org/125192

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

diff --git a/tools/tickprocessor.js b/tools/tickprocessor.js
index dfe60ae4b154d82b34593950e5603ecf37cee7bd..3a43d18c9f6763befca374618631515f72feac63 100644 (file)
--- a/tools/tickprocessor.js
+++ b/tools/tickprocessor.js
@@ -433,7 +433,7 @@ CppEntriesProvider.prototype.parseVmSymbols = function(
   function addPrevEntry(end) {
     // Several functions can be mapped onto the same address. To avoid
     // creating zero-sized entries, skip such duplicates.
-    if (prevEntry && prevEntry.start != end) {
+    if (prevEntry && prevEntry.start < end) {
       processorFunc(prevEntry.name, prevEntry.start, end);
     }
   }
@@ -478,7 +478,7 @@ function UnixCppEntriesProvider() {
 inherits(UnixCppEntriesProvider, CppEntriesProvider);
 
 
-UnixCppEntriesProvider.FUNC_RE = /^([0-9a-fA-F]{8}) . (.*)$/;
+UnixCppEntriesProvider.FUNC_RE = /^([0-9a-fA-F]{8}) [tT] (.*)$/;
 
 
 UnixCppEntriesProvider.prototype.loadSymbols = function(libName) {