Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Vincent Rubiolo <vincent dot rubiolo at st dot com>]

Thank you Richard, Bill and Yves for your replies,

More info about on what I want to achieve : the conversion of our project from 
ADS 1.2 to the GNU toolchain. The project uses some code which is provided by 
another company for hardware interfaces along our own code.

As of today, the conversion seems fine. Files were adapted and the global 
behaviour is acceptable (some regression tests still failing though).

Richard :
The --mstructure-size=8 option helped gaining little space. Quoting from ADS 1.2 
manual, the alignment rules are much more complex than those of gcc for 
structures _members_ :

Field alignment
Structures are arranged with the first-named component at the lowest address. 
Fields are aligned as follows:
·A field with a char type is aligned to the next available byte.
·A field with a short type is aligned to the next even-addressed byte.
·Bitfield alignment depends on how the bitfield is declared. See Bitfields in 
packed structures for more information.
·All other types are aligned on word boundaries.

So we may run into problems with others structs (see end of post for expl of 
problematic struct).


Bill and Yves :
The padding problem came of the following struct declarations :

typedef struct
{
... (16 bits members)
  unsigned short int Bob;
  struct2 Jane;
... (other stuff)
} struct1;

where struct2 is the following :

typedef struct
{
   unsigned char   A[11];
   unsigned char   Reserved;
} struct2;

With ADS, Bob is aligned on a 16 bits boundary and Jane begins just after so 
everything is fine. With gcc, padding is inserted after Bob to reach a 32bit 
boundary hence system crashes because these structures are HW mapped. The packed 
attribute solved the issue for that struct.

Behind my question was the issue of code footprint.
I have found that the GNU toolchain produces code which is 30 to 50% bigger than 
the one of ADS, especially when debugging info is turned off. As I stated 
before, the project uses mixed ARM and THUMB code, so interworking is in the 
brawl. I am trying to figure, with the help of the binutils, why does gcc 
produces such big code.

We have two memory zones, RAM (little code, mainly data) and FLASH (code).
If debugging information is not enabled, ADS outstands GNU by 63% on FLASH and 
12% in RAM (optimised for size on both).
If debugging is enabled, the difference falls to 13 and 10% (still optimised or 
size for gcc, no optimisations for ADS).

I am still investigating and trying to find ways to reduce the footprint.

Thank you again for your consideration.

Regards,

Vincent