lkml.org 
[lkml]   [2013]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:perf/core] perf: Fix broken union in ' struct perf_event_mmap_page'

* Vince Weaver <vince@deater.net> wrote:

> On Tue, 17 Sep 2013, Vince Weaver wrote:
>
> >
> > This patch somehow breaks the perf-ABI.
> >
> > If I take a program that reads "mmap->cap_usr_rdpmc" and compile it
> > against the new header with this change (say from 3.12-rc1)
> > and then run it on an old kernel (say 3.11) then I get "0" for
> > cap_usr_rdpmc.
> >
> > If I take the same program and recompile against the old (without this
> > patch) header and run it on 3.11, I get the expected "1" value.
>
> To follow up, the original case:
>
> union {
> __u64 capabilities;
> __u64 cap_usr_time : 1,
> cap_usr_rdpmc : 1,
> cap_____res : 62;
> };
>
> Then mmap->usr_rdpmc=1; gets assembled as
>
> 400420: 80 0d 11 05 20 00 02 orb $0x2,0x200511(%rip)

Hm, how can it be 0x2? Didn't you mix up the two assemblies accidentally?

>
> The new version
>
> union {
> __u64 capabilities;
> struct {
> __u64 cap_usr_time : 1,
> cap_usr_rdpmc : 1,
> cap_usr_time_zero : 1,
> cap_____res : 61;
> };
> };
>
> mmap->usr_rdpmc=1; gets assembled as
>
>
> 400427: 80 0d 02 05 20 00 01 orb $0x1,0x200502(%rip)
>
> note the difference in the or value.

Here the value should be 0x2, as cap_usr_rdpmc move to the second bit.

Right?

Ingo


\
 
 \ /
  Last update: 2013-09-19 11:01    [W:1.096 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site