Good one [LWN.net]

Good one

Posted Sep 26, 2013 16:17 UTC (Thu) by deater (subscriber, #11746)
In reply to: Good one by etienne
Parent article: A perf ABI fix

One thing not really addressed is how bitfields run opposite ways on little endian and big endian systems.

Not a problem in most cases, but perf_event describes some bitfields
such as struct perf_branch_entry that get written to disk directly.

So if you record a session, then move it to an opposite-endian machine and try to read it back in you have problems.

(Log in to post comments)

Good one

Posted Sep 27, 2013 12:05 UTC (Fri) by etienne (subscriber, #25256) [Link]

> opposite ways on little endian and big endian systems

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).
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.

I still prefer:
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.