Re: [ECOS] Yet another ARM alignment question

["Wilson Kwan" <wilson at kinesphere dot com>]

Sorry, forgot to attach the code snippets.


> 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
>
>

test3.c

Makefile