Messages in this thread | | | From | Michael Ellerman <> | Subject | Re: [PATCH v1 01/13] perf/core: add union to struct perf_branch_entry | Date | Sun, 19 Sep 2021 20:27:38 +1000 |
| |
Stephane Eranian <eranian@google.com> writes: > On Fri, Sep 17, 2021 at 5:38 AM Michael Ellerman <mpe@ellerman.id.au> wrote: >> >> Stephane Eranian <eranian@google.com> writes: >> > Hi, >> > >> > On Fri, Sep 17, 2021 at 12:05 AM Michael Ellerman <mpe@ellerman.id.au> wrote: >> >> >> >> Stephane Eranian <eranian@google.com> writes: >> >> > Hi, >> >> > >> >> > Thanks for fixing this in the perf tool. But what about the struct >> >> > branch_entry in the header? >> >> >> >> I'm not sure what you mean. >> >> >> >> We can't change the order of the fields in the header, without breaking >> >> existing userspace on BE systems. >> >> >> > Ok, I think I had missed that. You are saying that the >> > #ifdef (__BIG_ENDIAN_BITFIELD) vs __LITTLE_ENDIAN_BITFIELD >> > >> > is only added to kernel-only data structures? >> >> No, we *should* have used __BIG/LITTLE_ENDIAN_BITFIELD for the uapi >> definition, but we forgot. >> > But are you suggesting it cannot be fixed?
I'm not saying it *cannot* be fixed
But I don't think it's sufficiently broken to warrant fixing.
Just adding the __BIG/LITTLE_ENDIAN_BITFIELD ifdefs would break the ABI for existing users.
So we'd have to continue to support the existing bitfield layout, and then add a flag for userspace to request a new bitfield layout where the bit numbers are stable across endian.
But that's way too much effort IMHO.
The existing definition works fine, *except* when perf.data files are moved between machines of different endianness. That is pretty rare these days, and can be handled in the perf tool easily enough.
>> >> It's annoying that the bit numbers are different between LE & BE, but I >> >> think it's too late to change that. >> >> >> > I agree. >> > >> >> So nothing should change in the branch_entry definition in the header. >> >> >> >> My comment on your patch was that adding the union with val, makes it >> >> easier to misuse the bitfields, because now the values can be accessed >> >> via the bitfields and also via val, but when using val you have to know >> >> that the bit numbers differ between BE/LE. >> >> >> > Ok, I get it now. We do not need to expose val to user. This is added >> > for kernel code convenience only. >> >> Yeah. Putting the union with val in the uapi encourages userspace to >> misuse val to bypass the bitfields, and that risks causing endian bugs. >> >> > But if we keep it in kernel, that may break some other rules about >> > uapi headers. >> >> I don't follow what you mean there. >> >> We could use #ifdef __KERNEL__ in the uapi header to make the union >> kernel-only, see below, but it's pretty gross. >> >> struct perf_branch_entry { >> __u64 from; >> __u64 to; >> #ifdef __KERNEL__ >> union { >> __u64 val; /* to make it easier to clear all fields */ >> struct { >> #endif >> __u64 mispred:1, /* target mispredicted */ >> predicted:1,/* target predicted */ >> in_tx:1, /* in transaction */ >> abort:1, /* transaction abort */ >> cycles:16, /* cycle count to last branch */ >> type:4, /* branch type */ >> reserved:40; >> #ifdef __KERNEL__ >> }; >> }; >> #endif >> }; >> >> >> If we just do the inline I suggested we can clear the flags in a single >> source line, and the generated code seems fine too, eg: >> >> static inline void clear_perf_branch_entry_flags(struct perf_branch_entry *e) >> { >> e->mispred = 0; >> e->predicted = 0; >> e->in_tx = 0; >> e->abort = 0; >> e->cycles = 0; >> e->type = 0; >> e->reserved = 0; >> } >> > Ok, let's do the inline then. That looks like a cleaner solution to me > assuming the compiler does the right thing.
It did when I checked with GCC 10.
cheers
| |