On Mon, Jan 21, 2013 at 8:58 PM, Martin Roth <[email protected]> wrote: > I've run into what looks like an issue with how romcc handles bitfields and > chars vs how the structure in static.c is created. > When I'm accessing a member of a structure that comes after a bitfield or a > single char between dwords or pointers, the code is grabbing data from a > different address than the actual location of the data. I've found that if > I add extra "reserved" bits to the bitfield to fill it up to a dword, and > extra chars to do the same, everything works as expected. > > I'm currently running into this trying to access data from the 'device' > structure from static.c in romstage. If I don't add any changes, I'm > getting a null pointer returned because I'm trying to access my data 6 bytes > too early: mov esi,DWORD PTR [eax+0x86] > > Here's what the structure currently looks like: > > unsigned int enabled : 1; /* set if we should enable the device */ > unsigned int initialized : 1; /* set if we have initialized the > device */ > unsigned int on_mainboard : 1; > struct pci_irq_info pci_irq_info[4]; > u8 command; > ... > ROMSTAGE_CONST void *chip_info; > > > Here's how I need to fix it to access chip_info correctly: > unsigned int enabled : 1; /* set if we should enable the device */ > unsigned int initialized : 1; /* set if we have initialized the > device */ > unsigned int on_mainboard : 1;
Actually the :1 stuff is old-school for "bool". Bit-fields were proclaimed a botch by their creator; here is another examply why. I would feel better if we just got rid of the :1 completely and kept it simple. I doubt the storage we save is worth the effort. ron -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
