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] [thread-next>] [day] [month] [year] [list]

Message-ID: <51FD095F.8060208@intel.com>
Date:	Sat, 03 Aug 2013 16:45:03 +0300
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
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

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.

>
> 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.
--
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/