Switch from nm to objdump for the cygprofile tools.

tools/cygprofile/symbol_extractor.py

+#!/usr/bin/python
+# Copyright 2015 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+"""Utilities to get and manipulate symbols from a binary."""
+
+import collections
+import os
+import re
+import subprocess
+import sys
+
+sys.path.insert(
+    0, os.path.join(sys.path[0], '..', '..', 'third_party', 'android_platform',

[pasko, 2015/01/29 12:24:42]

why not sys.path.append()?

let's also not make any assumption about where the scripts is invoked from,
please do it similarly to:
tools/android/checkstyle/checkstyle.py

[Benoit L, 2015/01/29 13:10:30]

Because python's standard library also has a module named "symbol". And it is
not possible to import the parent directory, as it lacks the __init__.py file
required to make it importable.
The same mechanism is used in asan_symbolize.py.

Done for the path.

+                    'development', 'scripts'))
+import symbol
+
+
+# TODO(lizeb): Change symbol.ARCH to the proper value when "arm" is no longer
+# the only possible value.
+_OBJDUMP_BINARY = symbol.ToolPath('objdump')
+
+
+SymbolInfo = collections.namedtuple('SymbolInfo', ('name', 'offset', 'size',
+                                                   'section'))
+
+
+def _FromObjdumpLine(line):
+  """Create a SymbolInfo by parsing a properly formatted objdump output line.
+
+  Args:
+    line: line from objdump
+
+  Returns:
+    An instance of SymbolInfo if the line represents a symbol, None otherwise.
+  """
+  # All of the symbol lines we care about are in the form
+  # 0000000000  g    F   .text.foo     000000000 [.hidden] foo
+  # where g (global) might also be l (local) or w (weak).
+  parts = line.split()
+  if len(parts) < 6 or parts[2] != 'F':
+    return None
+  offset = int(parts[0], 16)
+  section = parts[3]
+  size = int(parts[4], 16)
+  name = parts[-1].rstrip('\n')
+  return SymbolInfo(name=name, offset=offset, section=section, size=size)
+
+
+def _SymbolInfosFromStream(objdump_lines):
+  """Parses the output of objdump, and get all the symbols from a binary.
+
+  Args:
+    objdump_lines: An iterable of lines
+
+  Returns:
+    A list of SymbolInfo.
+  """
+  symbol_infos = []
+  for line in objdump_lines:
+    symbol_info = _FromObjdumpLine(line)
+    if symbol_info is not None:
+      symbol_infos.append(symbol_info)
+  return symbol_infos
+
+
+def SymbolInfosFromBinary(binary_filename):
+  """Runs objdump to get all the symbols from a binary.
+
+  Args:
+    binary_filename: path to the binary.
+
+  Returns:
+    A list of SymbolInfo from the binary.
+  """
+  command = (_OBJDUMP_BINARY, '-t', '-w', binary_filename)
+  p = subprocess.Popen(command, shell=False, stdout=subprocess.PIPE)
+  try:
+    result = _SymbolInfosFromStream(p.stdout)
+    return result
+  finally:
+    p.wait()
+
+
+def GroupSymbolInfosByOffset(symbol_infos):
+  """Create a dict {offset: [symbol_info1, ...], ...}.
+
+  As several symbols can be at the same offset, this is a 1-to-many
+  relationship.
+
+  Args:
+    symbol_infos: iterable of SymbolInfo instances
+
+  Returns:
+    a dict {offset: [symbol_info1, ...], ...}
+  """
+  offset_to_symbol_infos = collections.defaultdict(list)
+  for symbol_info in symbol_infos:
+    offset_to_symbol_infos[symbol_info.offset].append(symbol_info)
+  return dict(offset_to_symbol_infos)
+
+
+def CreateNameToSymbolInfo(symbol_infos):

[pasko, 2015/01/29 12:24:42]

this function is only used in a test, is it going to be useful in a following
CL? If so, please add it there. Dead code is easy to forget about, you know.

[Benoit L, 2015/01/29 13:10:30]

Yes, it is going to be used. But I would prefer to separate the introduction of
common functions from the refactoring making use of them. Especially since this
method is tested.

What do you think?

[pasko, 2015/01/29 13:25:30]

since it confuses reviewers, that's usually worth an extra comment in the commit
description. So you are free to choose, whether to explain in the commit
description that the plan is to use this and that function in a coming-soon CL,
or just introduce things lazily when needed. I prefer the 2nd approach, because
it's less to write/explain.

+  """Create a dict {name: symbol_info, ...}.
+
+  Args:
+    symbol_infos: iterable of SymbolInfo instances
+
+  Returns:
+    a dict {name: symbol_info, ...}
+  """
+  return {symbol_info.name: symbol_info for symbol_info in symbol_infos}