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  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]
Date:	Fri, 25 Jul 2014 10:37:16 +0200
From:	Sebastian Andrzej Siewior <>
To:	Jiri Olsa <>,
	Mathieu Desnoyers <>
Subject: Re: [RFC] perf to ctf converter

On 07/24/2014 04:46 PM, Jiri Olsa wrote:
> hi,


> I made some changes over your branch:
>   git://
>   perf/ctf_convert
> following patches:
> (needs to be prettyfied, but hopefuly works and ilustrate the point)
>   perf tools: Iterate both common_fields and fields for tracepoit
>   perf tools: Use sample_type for generic fields
> we now add all fields available in the (via perf_event_attr:sample_type)
> and then for tracepoints we add both common_types and types fields
> I'm not sure we want to store made up data like symbol information,
> which could be obtained from IP anyway - how does babeltrace or any
> other CTF viewer do that?

This is probably for Mathieu best to answer. I *think* that it records
pointers and does not resolve symbols if possible.

I assumed it to be a good thing to do because you don't get the symbols
anymore once the library/binary is upgraded unless you look for the old
files. But then the very same problem you have perf since it does not
record the symbol.
So we could drop the symbol resolution but then we would have to teach
babeltrace and friends to resolve it.

> ---
> However I'm still not convinced 100% this is the way we want
> to go with this. What we do now is:
>   - read/parse events and convert them into ctf events
> What I/we do originally wanted to do was to use CTF to describe
> perf event as is defined via perf interface, so we dont need to
> parse data stream, but just store it.
> This would be handy/needed for CTF record support, where we _want_
> to store raw data from kernel and not parse it before that.
> I'll recheck and get back with issues I found with this approach.


> Meanwhile I think we can continue with what we have now,

Good :)

> I just wanted to share the other approach with you ;-)
> thanks,
> jirka

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists