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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130805163244.GD3228@ghostprotocols.net>
Date:	Mon, 5 Aug 2013 13:32:44 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>, Mike Galbraith <efault@....de>,
	Namhyung Kim <namhyung@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephane Eranian <eranian@...gle.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH V2 1/9] perf tools: add test for reading object code

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/