From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pv0-f176.google.com (mail-pv0-f176.google.com [74.125.83.176]) by mx1.pokylinux.org (Postfix) with ESMTP id 8D11B4C800B6 for ; Thu, 9 Jun 2011 01:48:22 -0500 (CDT) Authentication-Results: mx1.pokylinux.org; dkim=pass (1024-bit key; insecure key) header.i=@gmail.com; x-dkim-adsp=none (insecure policy) Received: by pve37 with SMTP id 37so828942pve.35 for ; Wed, 08 Jun 2011 23:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5coAIbq48b3WAtuqyZ3NH/kSTbdq7L0wW6AEPBB+9So=; b=Sw9JCTXf9FqkALBrWknRsSgWs75kHh5w7jeG1yDKkT/xdZ62AeE6VPsrEXNYIED8kD o72cU/UA2U7a6NLRiLltK7uE0jIQirDs7hQ116j0Awijp5Kck5aN12s2xPtesGOdpMjN RA1cAcm4F/sWLAcU0S0wfsQ0LXLEQsxeOGr+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=a7Jtr9cQAsD2EXsAuSi55sV3nwKKsGib4ON8gMYfb9PDk0oNLZItM/naDxoNs/gOS6 ouS9gVaiZDGzyMdyxsM3nxjkg0qALuMVDn6FgxbT9O/HL5HrxG4syIEjcGioFj5iC88F WYXmcKapTxlmHNNl3tcqOvtQx1U/QkaGwBUAM= Received: by 10.142.56.9 with SMTP id e9mr54249wfa.260.1307602101119; Wed, 08 Jun 2011 23:48:21 -0700 (PDT) Received: from [192.168.1.70] (99-57-141-118.lightspeed.sntcca.sbcglobal.net [99.57.141.118]) by mx.google.com with ESMTPS id k2sm1416826wfe.3.2011.06.08.23.48.18 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 23:48:20 -0700 (PDT) Message-ID: <4DF06CB0.1040501@gmail.com> Date: Wed, 08 Jun 2011 23:48:16 -0700 From: Khem Raj User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gary Thomas References: <4DEFB4BA.7050902@mlbassoc.com> <4DEFBD77.7000400@linux.intel.com> <4DF016F0.4080106@gmail.com> <4DF02EDF.5040502@mlbassoc.com> In-Reply-To: <4DF02EDF.5040502@mlbassoc.com> Cc: Poky Project Subject: Re: BeagleBoard using GCC 4.6.0 X-BeenThere: poky@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Poky build system developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 06:48:22 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/08/2011 07:24 PM, Gary Thomas wrote: > On 06/08/2011 06:42 PM, Khem Raj wrote: >> On 06/08/2011 11:20 AM, Saul Wold wrote: >>> On 06/08/2011 10:43 AM, Gary Thomas wrote: >>>> Now that Poky is using GCC 4.6.0, has anyone actually checked the >>>> operation on the BeagleBoard? I suspect that you'll find that the >>>> EHCI USB does not work. I can't really check here as I don't trust >>>> the EHCI on my BeagleBoard rev C3 (not xM). >>>> >>>> That said, I've tried this new compiler (previously reported) on >>>> my own OMAP/3530 board which uses the same 2.6.37 kernel (just not >>>> the linux-yocto version). When I build my kernel with GCC 4.5.2, >>>> it works perfectly, but fails with GCC 4.6.0 (I trust the hardware). >>>> >>>> I've isolated it down to at least the function 'ehci_hub_control' >>>> (but I suspect the problem is more fundamental). Comparing the code >>>> generated by the two compilers with the same source tree, this function >>>> is dramatically different. I can see why it's failing, I just don't >>>> know why the compiler is doing what it's doing. >>>> >>> >>> Gary, >>> >>> I am not sure if Khem Raj is on this list, so I am forwarding it to him, >>> he might have some insight. >>> >>> Sau! >>> >>> >>>> The lines at drivers/usb/host/ehci-hub.c:841 >>>> case GetPortStatus: >>>> if (!wIndex || wIndex > ports) >>>> goto error; >>>> wIndex--; >>>> status = 0; >>>> temp = ehci_readl(ehci, status_reg); >>>> >>>> are being compiled very differently. >>>> >>>> With GCC 4.5.2: >>>> 0xc0229810 : cmp r3, #0 ; 0x0 >>>> 0xc0229814 : beq 0xc0229df8 >>>> >>>> 0xc0229818 : cmp r3, r0 >>>> 0xc022981c : bgt 0xc0229df8 >>>> >>>> 0xc0229820 : sub r8, r3, #1 ; 0x1 >>>> 0xc0229824 : ldr r5, [r7, #4] >>>> 0xc0229828 : uxth r8, r8 >>>> 0xc022982c : dmb sy >>>> >>>> With GCC 4.6.0: >>>> 0xc0221630 : cmp r3, #0 ; 0x0 >>>> 0xc0221634 : beq 0xc0221d7c >>>> >>>> 0xc0221638 : cmp r3, r0 >>>> 0xc022163c : bgt 0xc0221d7c >>>> >>>> 0xc0221640 : sub r7, r3, #1 ; 0x1 >>>> 0xc0221644 : add r3, r11, #16 ; 0x10 >>>> 0xc0221648 : add r3, r8, r3, lsl #2 >>>> 0xc022164c : uxth r7, r7 >>>> 0xc0221650 : ldrb r5, [r3, #5] >>>> 0xc0221654 : ldrb r2, [r3, #4] >>>> 0xc0221658 : orr r5, r2, r5, lsl #8 >>>> 0xc022165c : ldrb r2, [r3, #6] >>>> 0xc0221660 : ldrb r3, [r3, #7] >>>> 0xc0221664 : orr r5, r5, r2, lsl #16 >>>> 0xc0221668 : orr r5, r5, r3, lsl #24 >>>> 0xc022166c : dmb sy >>>> >>>> As you can see, the old compiler accesses the ehci status register >>>> in a single access, the new compiler dances around and makes multiple >>>> accesses, which in the end get very incorrect data (I think that this >>>> register is like many which clear bits on reads). >>>> >>>> Any ideas where I can go with this? I'm really trying to keep up with >>>> Poky/Yocto, but this move to GCC 4.6.0 has broken my ARM targets :-( >>>> I do have PowerPC targets as well - they seem fine (from limited >>>> testing) >>>> with the new compiler. >>>> >>>> Note: if you want to see the whole function disassembly, look at >>>> http://www.mlbassoc.com/poky/ehci_hub_control-disassembly-gcc-4.5.2 >>>> http://www.mlbassoc.com/poky/ehci_hub_control-disassembly-gcc-4.6.0 >>>> >>>> Thanks >>>> >> >> OK. thanks for sending the sample code. >> Can you add -fstrict-volatile-bitfields option to CFLAGS while >> compiling this file or even the kernel for test sake ? >> and see if the problem goes away ? > > Sorry, this doesn't seem to make any difference in the generated code. > Hardly surprising as the register in question is a simple u32, not a > bitfield. > I reduced the testcase a bit further and it seems the bug is similar to http://gcc.gnu.org/bugzilla/PR45819 but a bit different that in this case -fstrict-volatile-bitfields does not help a fix for this particular problem is diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h index 6563802..b8c1833 100644 --- a/include/linux/usb/ehci_def.h +++ b/include/linux/usb/ehci_def.h @@ -194,7 +194,7 @@ struct ehci_dbg_port { u32 data47; u32 address; #define DBGP_EPADDR(dev, ep) (((dev)<<8)|(ep)) -} __attribute__ ((packed)); +} __attribute__ ((packed,aligned(__alignof__(int)))); #ifdef CONFIG_EARLY_PRINTK_DBGP #include since this particular structure all elements are integers but there might be more packed structures which have say char or short ints and are not necessarily ordered in the descending order of alignment Try it out and see if it helps