[ECOS] Yet another ARM alignment question

Wilson Kwan wilson@kinesphere.com
Wed Apr 25 08:10:00 GMT 2001


Hi Lewin,

> Hello Wilson,
>
> >My question is has anyone solved the word and dword alignment problems on
> >ARM? Is is any combination of gcc compiler options that will overcome
this
> >limitation albeit at a performance cost. What about an alignment trap
>
> 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
> instructions to access the misaligned data items in those structures; is
> that what you're asking? The performance cost of doing this globally is
> _high_ and it's best avoided!

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
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
arm-elf-gcc version 2.95.2 on Win NT 2000. I'm willing to take the
performance hit for now and will fix the general problem when I have more
time.

>
> Is this a theoretical question or do you have an actual problem? (Can you
> post a little sample code along with a description of the symptom?) I
can't
> see where it would be an issue except in certain structures (e.g. my
> problem I had a while back generating structs to reflect various FAT
> structures). gcc will normally handle pointer arithmetic and dereferencing
> for you without difficulty.

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?

Thanks again Lewin. As always you're a great help.

Wilson




More information about the Ecos-discuss mailing list