Jonas Maebe wrote:
On 12 jun 2007, at 13:45, Jonas Maebe wrote:
After noticing that gdb does not print 64 bit fields of (bit)packed records properly if they don't start on a byte boundary (both with fpc and with gpc), I decided to check what gcc does. It turns out that gcc (4.0.1, Mac OS X/ppc) only bitpacks values up to and including 59 bits. Fields declared as 60-64 bits are automatically aligned to the target-specific alignment boundary.
I've found my answer: http://www.linux-foundation.org/spec/ELF/ppc64/PPC- elf64abi-1.9.html#BITFIELD
Bit fields cause records to be split up in "storage units", and a field cannot cross the boundary of such a storage unit. If it does, then you have to pad the rest of the previous storage unit and start a new one for the current field (something which fpc does not yet do, and gpc apparently also not in all cases, at least not in "gpc version 20051116, based on gcc-3.4.5" for Mac OS X, which is of course fairly old).
And to make things more fun, there are apparently a lot of differences regarding how large such a "storage unit" is...
AFAIK this padding is part of C language specification. What other langages do is subject to language/compiler specification. In particular, I think that Ada requires support for arbitrary bitfield layout (including bitfields that go across word boundaries). I belive that current gpc behaviour is a concious decision to have better semantics that the one given by C. gcc backends is flexible, AFAIK gpc just uses backend support.
IMHO gdb should just correctly display such bitfields in gpc generated programs -- if not there is bug somewhere. ATM I can not say if the bug is in gpc frontend (missing some annotations) gcc buckend (emmiting incorrect debug info), gdb (mishandling debug info) or maybe brain damaged specification of debug info (basic stabs can handle only simple cases and frequently require nonstandard extensions).