Messages in this thread | | | Date | Tue, 24 Jun 2014 12:21:08 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [PATCH 2/7] perf trace: add support for pagefault tracing |
| |
Em Tue, Jun 24, 2014 at 04:46:20PM +0400, Stanislav Fomichev escreveu: > > > I think we may try to print [ip.dso+ip.offset] if we can't resolve ip symbol, > > > but I don't want dso@symbol+offset because if we have symbol, dso is > > > probably (?) redundant (ok, at least for me).
> > Well, I don't think it is :-)
> > dso->short_name should disambiguate 99.9% of the cases tho. Perhaps we > > can use --verbose, as in other places, to switch using dso->long_name, > > for cases where multiple versions of a library are used, some in non > > standard paths, which sometimes puzzles people looking at the tools > > output.
> If we use --verbose it will result in noise besides short/long names > (like looking up debug symbols, etc). > But I'm still not convinced we need to always print dso of ip, we already have > target process and symbol (if we have dbg symbols), this should be > enough to understand what code path triggered fault.
> > > It also seems we don't need to resolve symbol of pagefault address
> > Well, in some cases if we can resolve to a variable, why not? > If we fault into data map, we resolve to nothing, right? But if we > fault into some executable map, we can resolve some symbol. But is it > really useful to know (because for me it's much more interesting to know > which dso and offset we fault into, not the actual symbol)?
> What I think makes sense it to have current (default) format: > [ip.sym+ip.offs] => [addr.dso.long+addr.offs]
> And --verbose format, which will use dso.long@symbol+offset for addr and ip. > So by default we have somewhat readable and concise information, and if we > need to gather all possible details we may use --verbose. What do you > think?
We can go with that, yes.
- Arnaldo
| |