In case you are wondering what gcc will do the following on ARM targets by default:
1) 16 bit quantities start on a word boundary (address divisible by 2) 2) 32 bit quantities start on a dword boundary (address divisible by 4) 3) structures start on a dword boundary. 4) structure sizes are an even number of dwords. A most illustrative example of these rules is actually found in <arpa/tftp.h>: struct tftphdr { short th_opcode; /* packet type */ union { unsigned short tu_block; /* block # */ short tu_code; /* error code */ char tu_stuff[1]; /* request packet stuff */ } __attribute__ ((__packed__)) th_u; char th_data[1]; /* data or error string */ } __attribute__ ((__packed__)); On the ARM, by default this structure is 12 bytes long: - 2 bytes for th_opcode - 2 byte hole as the union has to start on a dword boundary - 4 bytes for the union - tu_block, tu_code and tu_stuff share 2 bytes, - 2 bytes filler as the union must be an even number of dwords long - 1 byte for th_data - 3 bytes filler as the struct must be an even number of dwords long Notice you have to add the __attribute__ ((packed)) on both structures to get rid of the hole and filler bytes. Scott Simon Pickering wrote: > Right, I've recompiled the arm side test so that it has a structure > with members that are the same size as those tested on the DSP. My > apologies for my earlier mistake. > > >> What happens if you pack the structure as in >> >> typedef struct __attribute__ ((packed)) endian_test_struct { >> >> > > Thank you for the suggestion. > > On the DSP this is not accepted by the compiler (there might be other > options, but really I'm trying to match the padding of structures > between the two processors, so this is fine as you'll see below). I'm > using the following struct on the ARM: > > typedef struct endian_test_struct { > unsigned int iamulong1; // 32bit > unsigned short iamuint1; // 16bit > unsigned short iamuint2; // 16bit > unsigned int iamulong2; // 32bit > unsigned short iamuint3; // 16bit > unsigned int iamulong3; // 32bit > } endian_test_struct; > > With no packing pragma we get this: > > Byte #: Hex : > Byte 0: 78 > Byte 1: 56 > Byte 2: 34 > Byte 3: 12 > Byte 4: 34 > Byte 5: 12 > Byte 6: 34 > Byte 7: 12 > Byte 8: 78 > Byte 9: 56 > Byte 10: 34 > Byte 11: 12 > Byte 12: 34 > Byte 13: 12 > Byte 14: 0 > Byte 15: 40 > Byte 16: 78 > Byte 17: 56 > Byte 18: 34 > Byte 19: 12 > > So the short has been padded into the start of a 32bit space. This is > the same as happens on the DSP, so I should be able to copy the > structure over and then fiddle with the endianness of its members. > > With the packing pragma we get the following: > > Byte #: Hex > Byte 0: 78 > Byte 1: 56 > Byte 2: 34 > Byte 3: 12 > Byte 4: 34 > Byte 5: 12 > Byte 6: 34 > Byte 7: 12 > Byte 8: 78 > Byte 9: 56 > Byte 10: 34 > Byte 11: 12 > Byte 12: 34 > Byte 13: 12 > Byte 14: 78 > Byte 15: 56 > Byte 16: 34 > Byte 17: 12 > > Which as you suggest has removed the padding and produced a shorter struct. > > Cheers, > > > Simon > > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers