From: David Ahern <dsahern@gmail.com>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, acme@redhat.com,
peterz@infradead.org, mingo@elte.hu
Subject: Re: [PATCH] perf: make perf.data more self-descriptive (v4)
Date: Mon, 12 Sep 2011 08:33:02 -0600 [thread overview]
Message-ID: <4E6E181E.9080506@gmail.com> (raw)
In-Reply-To: <CABPqkBSfQo5E=MJ913E--dc8Fi7VLcFSGNbBf60tOnTLMuVN_w@mail.gmail.com>
On 09/12/2011 07:54 AM, Stephane Eranian wrote:
>> The problem with endianness handling I mentioned last week is related to
>> the assumption that the HEADER_BUILD_ID is set. In my test case it is
>> not (-B flag on perf-record) and that causes the aborts. A problem for
>> another day which I can address it when I submit the patch to handle
>> swapping for the feature mask.
>>
> Ok, now I understand your point better.
>
> The thing is that the endianess detection done by perf is currently broken.
> It assumes that if the size of perf_event_attr saved in the file (attr_size)
> does not match sizeof(perf_event_attr) then it must be because of endianess
> issues. The reality is that it they can be different because the the ABI
> has been extended (and I am sure it will), and this a perf tool may
> have a larger struct perf_event_attr, than an old perf.data file, yet it
> should be able to read it. We need to fix this issue now and not once
> we hit the problem with extended ABI. I have a couple of ideas on this
> and they revolve around using the magic prefix as the indicator of endianess
> (and also detect older perf.data files).
There is some handling of older perf data files. For example, data files
without the adds_features mask are handled -- see
perf_file_header__read(), if (header->size != sizeof(*header)) {}
The swapping of the adds_features mask is a mess because the mask was
declared as an array of unsigned longs (util/include/linux/types.h).
I do have it working now -- analyzing 32-bit PPC files on 32-bit and
64-bit x86 hosts.
I have a patch to take a best guess on the feature mask. Your patchset
actually helps there since the new features are on by default with no
off switch. I guess to make it more robust I should add an endian
feature mask and require it to be set rather than depending implicitly
on the existence of other flags. Once Arnaldo picks up this patch I'll
send out one for endianness handling of the features mask.
David
next prev parent reply other threads:[~2011-09-12 14:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-07 19:10 [PATCH] perf: make perf.data more self-descriptive (v4) Stephane Eranian
2011-09-08 15:27 ` David Ahern
[not found] ` <CABPqkBRKcxeTDMyVYPXU6AQEY-Hp2bnE03ebEtvjYWde2JKqoQ@mail.gmail.com>
2011-09-08 15:37 ` David Ahern
2011-09-08 15:42 ` Stephane Eranian
2011-09-12 13:45 ` David Ahern
2011-09-12 13:54 ` Stephane Eranian
2011-09-12 14:33 ` David Ahern [this message]
2011-09-12 14:40 ` Stephane Eranian
2011-09-12 14:43 ` Peter Zijlstra
2011-09-12 14:47 ` Stephane Eranian
2011-09-13 14:40 ` Arnaldo Carvalho de Melo
2011-09-16 14:35 ` Stephane Eranian
2011-09-16 14:37 ` Peter Zijlstra
2011-09-16 14:44 ` Stephane Eranian
2011-09-16 14:52 ` David Ahern
2011-09-16 14:56 ` Stephane Eranian
2011-09-16 14:50 ` David Ahern
2011-09-16 15:19 ` Peter Zijlstra
2011-09-16 15:33 ` David Ahern
2011-09-16 15:42 ` Peter Zijlstra
2011-09-16 16:34 ` Stephane Eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E6E181E.9080506@gmail.com \
--to=dsahern@gmail.com \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox