Re: [PATCH V2 1/9] perf tools: add test for reading object code

[Arnaldo Carvalho de Melo]

Em Sat, Aug 03, 2013 at 04:45:03PM +0300, Adrian Hunter escreveu:
> On 31/07/2013 5:17 p.m., Arnaldo Carvalho de Melo wrote:
> >Em Wed, Jul 31, 2013 at 12:13:50AM +0300, Adrian Hunter escreveu:
> >>Using the information in mmap events, perf tools can read object
> >>code associated with sampled addresses.  A test is added that
> >>compares bytes read by perf with the same bytes read using
> >>objdump.

> >So this parses objdump output, and we also already have the annotation
> >logic that does that too, have you thought about having common routines
> >for these two cases?
 
> The annotation logic strips out the bytes (--no-show-raw) whereas
> the test extracts only the bytes, so they are not currently
> compatible.

Yeah, they are not, suggestion was to make it so at some point, as there
are many possible use cases that would use one, the other or both info.
 
> >I mean the disasm_line, ins, ins_ops, ins_operands classes, that now
> >lives in util/annotate.h but could be moved somewhere else,
> >disconnecting it as much as possible from annotation, because probably
> >there are more cool things we could do with that... :-)

> >We could certainly do it incrementally, merging your current patch
> >series and then working on sharing code on these two use cases, but
> >perhaps you can do it now?

> >What do you think?
 
> I expect replacing objdump with library calls will end up being the
> way forward.

Yes, and the recent work from Vitillo/Namhyung shows promise, but then
making it work with existing structs created from parsing the objdump
output shuld be ok.

At some point just dropping the parsing would then be transparent to
users of such structs.

But I should try it myself and see how it goes, to show what I mean :-)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/