Emit symbol maps for compiled code for use by the Linux perf tool.

Emit symbol maps for compiled code for use by the Linux perf tool.

Committed: https://code.google.com/p/dart/source/detail?r=9922

[siva, 2012-07-25 22:25:23]

lgtm

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc...
runtime/bin/main.cc:148: #endif
Could you abstract this away into os.h as OpenPerfSymbolsFile or something like
that instead of a #if defined(..) over here.

Also you wouldn't need the CurrentProcessId function if this is abstracted out.

[cshapiro, 2012-07-25 22:52:53]

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc...
runtime/bin/main.cc:148: #endif
I do not feel good about that as Linux is the only platform that would ever
provide a functioning definition.  And, because of the File::Open call, that
definition cannot appear in VM-specific code.  Having a prototype in os.h and an
implementation somewhere under bin seems awkward, I doubt that is what you
intended in this comment.

As an aside, there are profilers, such as Intel's VTune and some Valgrind tools,
which run on more than one of our targets.  Putting definitions for these
targets in the global namespace seems justifiable.

[siva, 2012-07-25 23:19:52]

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc...
runtime/bin/main.cc:148: #endif
Sorry I meant platform.h which is in the 'bin' directory and not os.h

I would think it is ok to have empty unreachable methods on macos and win for
it.

On 2012/07/25 22:52:54, cshapiro wrote:
> I do not feel good about that as Linux is the only platform that would ever
> provide a functioning definition.  And, because of the File::Open call, that
> definition cannot appear in VM-specific code.  Having a prototype in os.h and
an
> implementation somewhere under bin seems awkward, I doubt that is what you
> intended in this comment.
> 
> As an aside, there are profilers, such as Intel's VTune and some Valgrind
tools,
> which run on more than one of our targets.  Putting definitions for these
> targets in the global namespace seems justifiable.

[cshapiro, 2012-07-26 00:14:19]

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://chromiumcodereview.appspot.com/10831005/diff/2001/runtime/bin/main.cc...
runtime/bin/main.cc:148: #endif
Per our off-line conversation, I will add a TODO reminding us to find a better
place for this code.