Messages in this thread | | | Date | Thu, 19 Sep 2013 10:42:49 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |