Good one
Good one
Posted Sep 26, 2013 11:05 UTC (Thu) by etienne (guest, #25256)In reply to: Good one by khim
Parent article: A perf ABI fix
No, instead of reading the 2nd bit of unaligned byte, the compiler emits code to read bit (2+8) of aligned word. Bit stay at the same place.
Posted Sep 26, 2013 12:56 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Posted Sep 26, 2013 16:17 UTC (Thu)
by deater (subscriber, #11746)
[Link] (1 responses)
Not a problem in most cases, but perf_event describes some bitfields
So if you record a session, then move it to an opposite-endian machine and try to read it back in you have problems.
Posted Sep 27, 2013 12:05 UTC (Fri)
by etienne (guest, #25256)
[Link]
On my side of the world, you do have little-endian system and BI-endian systems: the processor may be big-endian, but then it always has to interact with at least one little-endian subsystem (could be as simple as a PCI card, more usually most subsystems).
I still prefer:
This will only work for read, not for writes. And even then only if int and not _Bool is used.
Good one
Good one
such as struct perf_branch_entry that get written to disk directly.
Good one
Then, they added stuff at the virtual memory layer to describe that memory mapped area as either little or big endian, which solves a small part of the problem, two bit fields still increment as 0b00, 0b10, 0b01, 0b11.
Then, big endian processor sort of disappeared.
struct status {
#ifdef LITTLE_ENDIAN
unsigned b1:1, b2:1, b3:1, unused:29;
unsigned xx;
#else
unsigned xx;
unsigned unused:29, b3:1, b2:1, b1:1;
#endif
}
than the 40 equivalent lines of #define, if I have a lot of those status.