Atrribute packed and aligned causes alignment trap on ERC32 (SPARC v7)

Ulf Ivraeus ulf.ivraeus@space.se
Mon May 30 15:30:00 GMT 2005


Hello all,


Problem Description
-------------------
I have encountered a problem when using packed bit-field structs in
combination with the "aligned" attribute when the latter is applied to the
variable declaration. The total size of my struct is one byte of which 7
bits are "unused" and one bit holds information. I have declared an
array-variable (10 elements) of this struct and added an aligned(4)
attribute to the variable in order to ensure that the array begins on an
word-aligned address.

When looping over the array entries and writing to the single bit in each of
them my program causes an "memroy not aligned" trap. I have found that the
"read-modify-write" of the bit-field in the second array entry is
responsible for the trap. It turns out that the compiler has generated code
that uses a "load double" instruction to read data from each entry even
thought the array entries are byte-aligned (due to the packed attribute in
my struct-declaration)


The problem was discovered when I started using gcc 3.2.3. I have previously
used 2.95.2 on the same code without this kind of problems.


Source code:
------------
The following code triggers the problem:
......................................................................
  typedef struct __attribute__((packed))
  {
    unsigned  b1_1    : 1;
    unsigned  unused  : 7;
  } MyByteStruct_T;

  MyByteStruct_T MyStructArr [10] __attribute__((aligned(4)));


<<< in function "main" >>>
 
  printf("-------------------------------------------------\n");
  printf("- sizeof(MyByteStruct_T)   = %d\n", sizeof(MyByteStruct_T));
  printf("- sizeof(MyStructArr)      = %d\n", sizeof(MyStructArr));
  printf("- sizeof(MyStructArr[0])   = %d\n", sizeof(MyStructArr[0]));
  printf("- sizeof(MyStructArr[1])   = %d\n", sizeof(MyStructArr[1]));
  printf("-------------------------------------------------\n");
  printf("- &MyStructArr[0] = 0x%08X\n", (int)&MyStructArr[0]);
  printf("- &MyStructArr[1] = 0x%08X\n", (int)&MyStructArr[1]);
  printf("-------------------------------------------------\n");
                  
  
  for (i = 0; i < 10; i++)
    MyStructArr[i].b1_1 = 1;
.......................................................................


Execution output:
-----------------
  -------------------------------------------------
  - sizeof(MyByteStruct_T)   = 1
  - sizeof(MyStructArr)      = 10
  - sizeof(MyStructArr[0])   = 1
  - sizeof(MyStructArr[1])   = 1
  -------------------------------------------------
  - &MyStructArr[0] = 0x0201A870
  - &MyStructArr[1] = 0x0201A871
  -------------------------------------------------
  Unexpected trap (0x07) at address 0x020012a8
  memory address not aligned



Questions:
Is there something fundamentally wrong with my code? Have I used the
"packed" and "aligned" attribues in a way that are not supported by GCC? (I
have tried to find proof of this in the documentation but not succeeded). 

If my code violates any constrains of the attribute usage - how shall I then
specify that I want a certain array of one-byte bit-field-structs to begin
on an 32-bit aligned address?

Is this a problem only in the version of GCC I'm using (3.2.3) ?



The following compiler flags are used:
 -Wall
 -04
 -mcpu=cypress

(The problem is present also with -00 instead of -04)

Release:
--------
gcc version 3.2.3

Environment:
------------
Cross-compiler for SPARC RTEMS running on Solaris 9.
Target is an ERC32 processor.

system type: (uname -a)
SunOS sunsrv3 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Fire-480R

gcc version (sparc-rtems-gcc -v)
Reading specs from
/home/sw_projects/ThesisWork/FileSystemForSmuMM/RTEMS/opt/rtems-4.6/bin/../l
ib/gcc-lib/sparc-rtems/3.2.3/specs
Configured with: ../gcc-3.2.3/configure --build=i686-pc-linux-gnu
--host=sparc-solaris --target=sparc-rtems --with-gnu-as --with-gnu-ld
--with-newlib --verbose --with-system-zlib --disable-nls
--enable-version-specific-runtime-libs --enable-threads=rtems
--prefix=/opt/rtems-4.6 --enable-languages=c,c++
Thread model: rtems
gcc version 3.2.3 (OAR Corporation
gcc-3.2.3-20040108/newlib-1.11.0-20030605-3)




More information about the Gcc-help mailing list