Re: [tracecompass-dev] Timestamps in the symbol provider

[Robert Kiss <robert.kiss@xxxxxxxxx>]

Hello Alexandre,

I propose instead of changing the signatures of the methods to create two new method and provide the default implementation into the ISymbolProvider. The default implementation, of course, will just delegate to the old methods.

ClassStackView need also to be updated to use the new methods.

Please add me as reviewer when you will push your changes.

Regards

Robert

On Tue, Mar 29, 2016 at 11:06 PM, Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx> wrote:

Hi Robert,

I am currently implementing a ISymbolProvider for LTTng-UST traces, and I am hitting a limitation. Since you designed most of this feature, I thought you could have some idea what the best approach would be.


A new feature of LTTng-UST 2.8 is the possibility to generate trace events for all dynamic library load and unload operations (dlopen()/dlclose() calls), along with the address at which each library was loaded. This means that a given memory address can refer to a different library, which means a totally different source location, depending on the time at which the query is made.

The current methods in ISymbolProvider however do not handle this concept, they assume that a given address always return the same symbol name or callsite at any location in the trace.

I would be tempted to change the following method signatures in ISymbolProvider:

  String getSymbolText(long address);
  ITmfCallsite getSymbolInfo(long address);

to:

  String getSymbolText(long timestamp, long address);
  ITmfCallsite getSymbolInfo(long timestamp, long address);


The existing BasicSymbolProvider would simply ignore the new parameter. But the upcoming provider for LTTng-UST 2.8 could make use of the timestamp to find out which library the application is calling into, if applicable.


Do you see any problem with this approach, and do you think it's semantically correct to introduce the notion of timestamps into the symbol provider?

Thanks!
Alexandre