This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: CYG_HAL_TABLE_END alignment
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Bart> On most architectures the compiler and linker will arrange
Bart> for the start of this structure to be aligned to a 4-byte
Bart> boundary, i.e. a byte of padding gets inserted. When the
Bart> compiler iterates through the table it thinks it has a
Bart> fred[] array with each entry properly aligned. The linker
Bart> does not see an array, it gets a number of individual
Bart> variables, but it will align each one's start to the
Bart> appropriate boundary. So no problems so far.
Peter> Yes, but the padding byte is "inside" the structure, E.G.
Peter> sizeof(struct fred) == 8 - isn't it?
Normally yes. However when people start adding packed attributes etc.
into the picture things get messy. The HAL table macros are supposed
to work irrespective of the data types used. I do not know the
circumstances which caused the alignment to be added to the table end
macro, but assume it was something along the lines I described.
Forcing the alignment for CYG_HAL_TABLE_END and using
CYG_HAL_TABLE_TYPE on the structure definition eliminates any
ambiguity and is the correct fix for the i2c code. Removing the
alignment in the CYG_HAL_TABLE_END would presumably break whatever
scenario caused the alignment to be added in the first place.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts