* Vince Weaver <vince@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|