[tracecompass-dev] Additional requirements for symbol providers

[Genevieve Bastien <gbastien+lttng@xxxxxxxxxxxx>]

Hi all,


I'm currently working on a feature to support perf traces to analyse the
callchain data. Perf uses mmap[2] events information to map symbol to
their origin library and, if available, the symbol it uses. It can use a
perf-map-agent to generate a file to map java symbols to the method
name. Perf already have their own command line to process perf data
files, so I have my unit tests right there! Trace Compass needs to match
perf perfectly and even more!


There's a few issues with symbol resolution with Trace Compass right now
that I will list here. I'll be working on fixing it, but please, if you
think of anything missing or wrong, let me know:


1- Symbol mapping files are per-process: if a trace contains symbols
from different processes, using the basic symbol provider with mapping
file may lead to wrong results for some of them. Solution would be to
have a naming scheme for files: [whatever]-[pid].[something] where, if a
pid is specified, this file only applies to symbols from that process.
So perf-2465.map would mean a symbol file for process 2465 (and all its
threads). If no pid is specified, the file will be used for all symbols
and may lead to erroneous results if many processes are being traced.


2- Symbol mapping file format may differ: The basic symbol provider
reads text file generated by nm with the following format [long hex
symbol address] [a letter] [the resolved symbol]. And there's usually a
symbol containing __END__ which marks the end of the symbol range. The
mapping files generated with perf-map-agent are a little different [long
hex symbol address] [size in hex] [resolved symbol]. There is no __END__
symbol, but the size allows to know where a symbol ends. And symbols may
contain others. Either we use the basic symbol provider to guess which
file it is dealing with and resolve the symbols accordingly, or add
another symbol provider. The former is easier: the user can just import
all his files and the rest decides which parser to use


3- Multiple symbol providers may resolve a symbol: If multiple symbol
providers resolve a symbol, which one to use? Now it only returns a
String, so no way to know if the corresponding symbol address is closer
to the desired symbol. There should be an aspect or a class to take care
of this, symbol provider return the base address of the resolved symbol
and the string and the aspect takes the closest to the address. This
behavior is already implemented in the BasicSymbolProvider class, but it
should also be cross-provider.


4- It should be possible to keep the symbol configuration across Trace
Compass reboots


So, I'll be working on the first 3 features in a very near future. When
I have those ready, I think the perf2ctf analysis will be about ready
and symbols resolved as expected.


Cheers,

Geneviève