From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2588 invoked by alias); 20 Jan 2009 13:19:28 -0000 Received: (qmail 2573 invoked by uid 22791); 20 Jan 2009 13:19:27 -0000 X-SWARE-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,BAYES_00,BOTNET,SPF_PASS X-Spam-Check-By: sourceware.org Received: from vms173009pub.verizon.net (HELO vms173009pub.verizon.net) (206.46.173.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Jan 2009 13:19:23 +0000 Received: from [10.211.54.154] ([71.250.197.14]) by vms173009.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KDR00HIWU3R7HI2@vms173009.mailsrvcs.net> for ecos-patches@ecos.sourceware.org; Tue, 20 Jan 2009 07:14:16 -0600 (CST) Date: Tue, 20 Jan 2009 13:19:00 -0000 From: Jose Vasconcellos Subject: Re: redboot fconfig crash with gcc 4.3.2 In-reply-to: <49758360.4020009@mlbassoc.com> To: Gary Thomas Cc: ecos-patches@ecos.sourceware.org Message-id: <4975CF46.7010203@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <4974FD62.9090602@verizon.net> <49758360.4020009@mlbassoc.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090105) X-IsSubscribed: yes Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2009-01/txt/msg00019.txt.bz2 Gary Thomas wrote: > Jose Vasconcellos wrote: >> Redboot gets an exception when trying to set any IP address with fconfig >> when using gcc-4.3.2 on an ixp425 target (armeb). The issue seems to be >> an alignment problem as val_ptr contains an odd address; it looks >> like gcc >> is optimizing and trying to do a copy on a word boundary. The removal of >> the cast fixes the problem. >> >> >> --- fconfig.c 2009-01-18 14:34:11.000000000 -0500 >> +++ fconfig.c.new 2009-01-18 14:35:22.000000000 -0500 >> @@ -388,7 +388,7 @@ >> break; >> #ifdef CYGPKG_REDBOOT_NETWORKING >> case CONFIG_IP: >> - memcpy(&hold_ip_val.s_addr, &((in_addr_t *)val_ptr)->s_addr, >> sizeof(in_addr_t)); >> + memcpy(&hold_ip_val.s_addr, val_ptr, sizeof(in_addr_t)); >> if (!_gethostbyname(line, &new_ip_val)) { >> return CONFIG_BAD; >> } >> > > Sounds like a *BUG* in the compiler. Have you reported it? > > This does more than remove the cast :-) What if the s_addr field is not > at the start of the structure? I know it hasn't moved in 25+ years, but > I don't like tossing correctness [even if only pedantic] away. > > Maybe there's another way to solve this. Does it happen on arm[el]? > This doesn't look like a compiler bug to me. I suspect that this problem affects other arm variants but I only have access to an ixp425. The code is incorrect as val_ptr is pointing to a place in a configuration buffer for the raw data. Imposing (via a cast) the structure is not the right solution. Note that a few lines down in the source, the copy in the other direction does not have such a cast. Jose