[ECOS] Yet another ARM alignment question

Lewin A.R.W. Edwards larwe@larwe.com
Wed Apr 25 08:42:00 GMT 2001


Hi Wilson!

> > If you specify -fpack-struct on the gcc command line, gcc will not align
> > data items in structures and will generate multiple ldrh/ldrb/strh/strb
>
>I tried -fpack-struct to no effect. I believe that it may be a broken
>option. I can get code to run properly if I use __attribute__ ((packed)). My

It works for me with gcc 2.95.2 (under cygwin/win2000). The code size is 
increased substantially, and the speed is affected very noticeably though 
(around 15% slowdown in my MPEG-1 software decoder, for instance).

>problem is that we have so much legacy code that it is not feasible to go
>through all of it and add this attribute at this time. I'm running

I know that problem. That is one of the reasons I started with 
-fpack-struct (also I was having trouble getting the attribute directive to 
work properly). When I delved deeper, I found that very few of my 
structures actually needed to be packed (only a few that mirror structures 
supplied by external hardware), so I got rid of -fpack-struct.

>I've attached a test piece of code that exhibits the problem. I'm sure many
>have encountered this before. The makefile uses the -fpack-struct option but
>doesn't seem to fix the problem. Defining PACKED and recompiling does. Do
>you know if there was a patch for gcc to fix this on Win NT?

The 2.95.2 I'm running was installed exactly per Red Hat's instructions on 
sources.redhat.com. No special patches.

I'll take a look at your code this afternoon (I'm about to go into a 
MEETING.. argh!), but note well! you should delete your build tree and 
recompile eCos itself from scratch with -fpack-struct if you intend to 
compile your application with that flag. Although it will partly work if 
you don't, Bad Things will happen if you give any eCos API a pointer inside 
one of your unaligned structures, since the eCos code will assume that 
everything is aligned.

Note that I have only tested -fpack-struct with eCos 1.3.1, though I don't 
see an obvious reason why it should break current sources unless there are 
assembly language routines in the OS that dereference pointers generated by 
C code.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"... a man who is endowed with real qualities of leadership will be tempted 
to refrain from taking part in political life; because [...] the situation 
does not call for a man who has a capacity for constructive statesmanship 
but rather for a man who is capable of bargaining for the favour of the 
majority. Thus the situation will appeal to small minds and will attract 
them accordingly."



More information about the Ecos-discuss mailing list