This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]