Re: [tracecompass-dev] Additional requirements for symbol providers

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

Hi, I know this is late, but it took me time to really get my head
around it.



On 17-08-09 04:00 PM, Genevieve Bastien wrote:
> Hi all,
<Snip>
> 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.
This is an excellent catch, especially when you can have two executables
with the same name. having the - makes sure windows95.exe or
windows95-1234.exe will not conflict.

>
> 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
The former seems like the safer bet IMO. We can infer the ends, so
feeding the data to a basic symbol provider seems like the right way to go.
>
>
> 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.
We now have a multiple aspects, I think this would be the way to go. See
LeelooDallas  MultiAspect<T> implements ITmfEventAspect<T>.

>
>
> 4- It should be possible to keep the symbol configuration across Trace
> Compass reboots
See the .properties folder of the supplementary files.
>
>
> 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
>
Looks awesome, I wish I looked at the use case earlier. It's obvious
once you see the problem.