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

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

Hi Robert,

I have finished the implementation and testing of the new UST provider, 
and I just pushed it to Gerrit.

Here is the patch adding the new methods to ISymbolProvider:
https://git.eclipse.org/r/#/c/69969/

which then leads up to
https://git.eclipse.org/r/#/c/69973/
which introduces the new LTTng-UST provider.


It also turned out that the concept of PID (process ID) was needed in 
the provider, since a trace can contain events from more than one 
process, and (virtual) addresses are specific to their process. By 
specifying PID/timestamp/address, then it should point to one and only 
one binary or library.

Let me know if you spot anything wrong in the patches.

Thanks!
Alexandre


On 2016-03-30 02:59 AM, Robert Kiss wrote:
> 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