On Aug 19, 2019, at 8:46 AM, Markus Fröschle <markus@mubf.de> wrote:
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the following code:
#include <stdint.h>
typedef uint32_t uuint32_t __attribute__((aligned(1)));
uint32_t getuuint32(uint8_t p[]) {
return *(uuint32_t*)p;
}
This is meant to prevent gcc to produce hard faults/address errors on architectures that do not support unaligned access to shorts/ints (e.g some ARMs, some m68k). On these architectures, gcc is supposed to replace the 32 bit access with a series of 8 or 16 bit accesses.
I originally came from gcc 4.6.4 (yes, pretty old) where this did not work and gcc does not respect the aligned(1) attribute for its code generation (i.e. it generates a 'normal' pointer dereference, consequently crashing when the code executes). To be fair, it is my understanding that the gcc manuals never promised this *would* work.
That has never been my understanding. I've always read the manual to say that "aligned" only INCREASES the alignment. The normal alignment is that specified by the ABI for the given data type (often, but not always, the size of the primitive type) -- or it is 1 for "packed".
So I use __attribute__ ((packed)) to request byte alignment, and, say, __attribute__ ((packed, aligned(2))) to specify alignment to 2 byte multiples.
paul