Hi Nate,

Structs with their first member being a word shouldn't be a problem. Important 
is the total size of the struct. If it is odd, then the compiler will reserve 
an odd number of bytes on the stack for the struct, and since the 
stack is top-down, it is then 'tail-aligned'.
Normally, the compiler will padd any struct to have an even size, and it will 
also padd members within the struct to be word-alinged too (except for 
byte-sized members). But if you override this using the packed 
attribute, you'll get strange results. After all, packing a struct tells the 
compiler to sh*t on any alignment.

I had a similar problem when I had to exchange data packets of different size 
in a stream. I solved the problem by declaring ALL struct members as char[n], 
using macros to extract the values by their member offset. 
This way I had no prblem dealing with long vbalues in network byte order, 
structs where byte and word values are mixed etc. It is slower than using 
aligned structs, but it is 100% alignment-safe. (and when used on 
both sides, it automatically takes care of endianess)
If you are the master of your structs, then do not use packed structs and 
reorder the members instead (pairing byte-sized ones), so you will only lose up 
to 1 byte per instance.
You shouldn't see any more problems then.

JMGross

----- Ursprüngliche Nachricht -----
Von: Bragg Nate
An: '[email protected]'
Gesendet am: 24 Mrz 2010 20:24:14
Betreff: [Mspgcc-users] Stack WORD alignment problem


Hello,

Since I last emailed this list, I've had great success with the mspgcc comp=
iler (I was using the windows installer release).  That is, up until late l=
ast week, when I got to a part of the codebase for the project I'm working =
on which declared a struct whose first member was a WORD.  I found that for=
 some reason the compiler was electing to allocate on the stack an instance=
 of this struct aligned at an odd memory address.  This causes the msp430 t=
o truncate any operations on this variable to the previous even address (ov=
erwriting a byte of another variable).  Obviously, this is no good.

In searching for a cure for my problem, I have recompiled mspgcc (I eventua=
lly picked up on the fact, I think after reading it the tenth time, that I =
should use 3.2.3), binutils (2.19 and 2.18), gdb (6.8), using the patches b=
oth from CVS and from Bazaar (both from the gcc-msp430x/gcc-3.3 and mspgcc-=
core/gcc/gcc-3.3, along with all the rest).  These all produced the same re=
sult, unfortunately - a misaligned WORD.

Then I came across an email thread from late 2008 that looked like it was a=
 similar problem (unaligned access of packed structs - Patch from Peter Jan=
sen), and attempted to apply this patch and recompile one last time.  Unfor=
tunately, my program now will not compile at all; the assembler returns a c=
ryptic "Error: missing operand".

I'm feeling a little forlorn here, and I'm really hoping that someone can h=
elp guide me - I would love to be able to use this product.  Is there any h=
ope that someone could update the windows installer to include the fix to t=
his (along with any other great updates I'm sure have accumulated in the la=
st year or so) ?  If not, is there a foolproof way I can carry this out?

Thank you in advance,

Nate Bragg


Reply via email to