lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-devel] [bug #26273] etharp.c : fix alignment issue in etharp_r


From: Bill Auerbach
Subject: RE: [lwip-devel] [bug #26273] etharp.c : fix alignment issue in etharp_raw
Date: Wed, 22 Apr 2009 09:45:04 -0400

I disagree that what you're seeing is a compiler bug.

For example:

u8_t buffer[10];
u32_t *ptr, i;

ptr = (u32_t *) &buffer[1];
i = *ptr;

This will fail in the same way.  It's an implicit copy of a u32_t - but it's 
not a compiler bug.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Guillaume du PONTAVICE
>Sent: Wednesday, April 22, 2009 4:42 AM
>To: Simon Goldschmidt; Guillaume du PONTAVICE; address@hidden
>Subject: [lwip-devel] [bug #26273] etharp.c : fix alignment issue in
>etharp_raw
>
>
>Follow-up Comment #4, bug #26273 (project lwip):
>
>ok here is the assembly dump
>
>
>ldl n = (Load local) Load the value from n words above WPTR.
>ldnlp n  = (Load non-local pointer) Load the value AREG + 4n.
>dup = duplicate top of stack
>stnl n = Store non-local Store a value to n words above AREG.
>rev = reverse AREG & BREG value
>adc n = add constant to AREG
>
>
>       -- Line 1081 (lwip/src/netif/etharp.c)
>..2719:        -- Line 1081 (lwip/src/netif/etharp.c)
>       ldl     5       -- hdr
>       ldnlp   7
>       dup
>       ldl     12      -- ipsrc_addr
>       ldnl    0
>       rev
>       stnl    0
>       -- Line 1082 (lwip/src/netif/etharp.c)
>..2720:        -- Line 1082 (lwip/src/netif/etharp.c)
>       ldl     5       -- hdr
>       adc     38
>       dup
>       ldl     14      -- ipdst_addr
>       ldnl    0
>       rev
>       stnl    0
>
>
>as we can see, ipsrc_addr field is word aligned (instruction ldnlp 7 :
>offset
>= 7  words = 28 bytes) a load word / store word operation is used.
>
>ipdst_addr field is not word aligned (instruction adc 38 : offset = 38
>bytes), but the compiler still uses a load word / store word operation.
>
>so it is a compiler bug.
>I will report a bug to ST but unfortunately I doubt I can get a compiler
>fix
>in a short term ....
>
>would it be possible to use the SMEMCPY alternative ?
>
>
>    _______________________________________________________
>
>Reply to this item at:
>
>  <http://savannah.nongnu.org/bugs/?26273>
>
>_______________________________________________
>  Message posté via/par Savannah
>  http://savannah.nongnu.org/
>
>
>
>_______________________________________________
>lwip-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]