Add pc to help identify unknown addresses.

[gdbentley]

Add the function's pc to the module name or the "unknown" string in order to identify where the unknown lies (useful for managed runtimes that are missing some reporting of JIT or other symbols) and to differentiate between unknowns.

[brendangregg]

Where does the "{PC}" style come from? If another Linux tool uses curly brackets to signify a PC, then good, we're following a convention. If instead we're making it up, then I might double check whether a convention already exists. Just trying to follow principle of least surprise.

[gdbentley]

It's made up. The tools that I know of (gdb, perf report, VTune, etc.) will either print a symbol or the address, not both. I didn't want to give up printing the module name if that was known though. I chose curly braces as a delimiter since they are not valid characters in identifiers in any language I'm aware of (e.g. C, C++, Java, PHP, Perl, or Python) and thus would not be found in a module or function name.

[brendangregg]

Ok, I've looked around. Things like oops messages, ftrace hist triggers, and lockstat will print raw addresses. The formats I've seen include address, 0xaddress, [address], and [<address>].

We're already using []'s. I'm tempted to go with <>, so that it's:

[unknown <ffffffff8104ba65>]

Which looks similar to a lockstat and oops message call stack format.

I tried it out with some production traces, and it increases the SVG size by between 15% and about 300%, for data that I think a lot of us won't use. I'm make this an optional parameter, like --addrs, so we can do it when desired.

[gdbentley]

I've made the suggested changes and rebased. Please have another look.

[brendangregg]

Thanks, works!