Historically I've worked around this by forcing the buffer to be aligned,
but that's not the right solution. I've seen other hints that mspgcc
doesn't handle non-aligned byte accesses correctly.
Based on a quick test with GCC/intel, something like this should work.
Please create a ticket on the mspgcc4 SourceForge project bug tracker so I
have somewhere to hang some test code. What you have below is clear and
sufficient; no more details necessary. Thanks.
Peter
On Tue, Nov 16, 2010 at 10:44 AM, Alexandre Boeglin <
[email protected]> wrote:
> Hello,
>
> I'm currently working with Contiki, on a platform that uses a
> MSP430F1611 uC.
>
> I'm using the git branch of mspgcc4, with gcc version 4.4.5 and libc
> version ti_20101114.
>
> Here are excerpts of the source code i'm trying to compile, preprocessed
> using the -E option:
> ################
> void *packetbuf_dataptr(void);
>
> struct cxmac_hdr {
> uint8_t dispatch;
> uint8_t type;
> };
>
> struct cxmac_hdr *hdr;
> hdr = packetbuf_dataptr();
> if(hdr->dispatch == 0 && hdr->type == 0x13) {
> [...]
> }
> ################
> The packetbuf_dataptr() function returns a pointer inside a byte array.
> The index of the returned pointer depends of the length of the header of
> a received packet.
>
> So, even if the byte array that is used to store the packet is aligned
> on an even address, the returned pointer can be an odd address if the
> header length length is odd.
>
> When compiling with -O0, everything's fine, as byte variants of the mov,
> tst and cmp instructions are used:
> ################
> 601c: b0 12 a0 88 call #0x88a0
> 6020: 84 4f 1c 00 mov r15, 28(r4) ;0x001c(r4)
> 6024: 1f 44 1c 00 mov 28(r4), r15 ;0x001c(r4)
> 6028: 6f 4f mov.b @r15, r15
> 602a: 4f 93 tst.b r15
> 602c: 1b 20 jnz $+56 ;abs 0x6064
> 602e: 1f 44 1c 00 mov 28(r4), r15 ;0x001c(r4)
> 6032: 5f 4f 01 00 mov.b 1(r15), r15 ;0x0001(r15)
> 6036: 7f 90 13 00 cmp.b #19, r15 ;#0x0013
> 603a: 14 20 jnz $+42 ;abs 0x6064
> ################
>
> But when compiling with -Os, the two tests inside the if condition are
> merged into one single cmp instruction:
> ################
> 567c: b0 12 8a 6a call #0x6a8a
> 5680: bf 90 00 13 cmp #4864, 0(r15) ;#0x1300, 0x0000(r15)
> 5684: 00 00
> 5686: 0d 20 jnz $+28 ;abs 0x56a2
> ################
>
> And in the event that r15 contains an odd address, its LSB is discarded,
> and the comparison is done against wrong bytes of the array.
>
> I believe this is a bug, but I'm not really familiar with gcc internals.
>
> Should I fill in a bug report ? Do you need additional details ?
>
> Is there an optimization option I could disable without too many side
> effects (I still need the size optimization for the code to fit on the
> uC)?
>
>
> Best regards,
> Alexandre Boeglin
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
