ODP: [lwip-devel] [bug #26273] etharp.c : fix alignment issuein etharp_raw

[Małowidzki , Marek]

I completely agree with that.
 
Additionally, how could a compiler properly align addresses that are 
dynamically computed, e.g., provided as a function's argument?
 
However...
 
We define ETH_PAD_SIZE to be (x*sizeof(long) + 2) to assure that an IP header 
(and transport-level headers, at the same time) is always properly aligned (as 
are IP addresses inside it). As etharp_hdr is defined as
 
struct etharp_hdr {

PACK_STRUCT_FIELD(struct eth_hdr ethhdr);

PACK_STRUCT_FIELD(u16_t hwtype);

PACK_STRUCT_FIELD(u16_t proto);

PACK_STRUCT_FIELD(u16_t _hwlen_protolen);

PACK_STRUCT_FIELD(u16_t opcode);

PACK_STRUCT_FIELD(struct eth_addr shwaddr);

PACK_STRUCT_FIELD(struct ip_addr2 sipaddr);

PACK_STRUCT_FIELD(struct eth_addr dhwaddr);

PACK_STRUCT_FIELD(struct ip_addr2 dipaddr);

} PACK_STRUCT_STRUCT;

 
then either sipaddr or dipaddr is not four-byte aligned (MAC addresses are 
6-byte long). The question appears, how the statement
 
hdr->dipaddr = hdr->sipaddr;
 
(struct to struct copy) is translated by a compiler. I believe that - if the 
alignement cannot be determined at a compile time - it should be translated 
(compiled) as a byte-by-byte memory copy (memcpy()). Maybe the compiler 
optimizes it as a double word assignment, which is wrong. Maybe switching the 
optimization off would help.
 
Marek

________________________________

Od: address@hidden w imieniu Bill Auerbach
Wysłano: Śr 2009-04-22 15:45
Do: 'lwip-devel'
Temat: RE: [lwip-devel] [bug #26273] etharp.c : fix alignment issuein etharp_raw



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



_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel

<<winmail.dat>>