From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 21:09:16 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 057EE262 for ; Fri, 28 Dec 2012 21:09:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id A812D8FC12 for ; Fri, 28 Dec 2012 21:09:15 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c12so13511684ieb.9 for ; Fri, 28 Dec 2012 13:09:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=RUBDMaOp6vcMhszYBTknYGJ+0o88fXIA2dKflLgRxMI=; b=kcVTR/l38QcNM3tp/rUj2mSpAU/DtVCjDCFTy/oiCnIPEOiEqJU8CbY+04++L0tJ6w 4Z83pVfCBFOx9aKw/E3deCiNiN34Pg50xejCdWlEfQlpttDz7655sgWx64NTFoELiQaH GinSYwddD0tyV/F93o42aOxh50zokk/8KVOOC3s7K20jNP+0mSJ0YDHAGFyVH8lFW45t bUbk7Ow+DOCGAAOcS4M19MSj9G+jd6fxhx9zsNMKhzY5yk6dwc03hflVaAYQRtLECPy5 QB6yeviExgyDA62NXLvq8XRQIOnxe5pDxLFqXx8pUfIr5gkST0dA797bHLsC9kxg4hre QlUQ== X-Received: by 10.50.153.200 with SMTP id vi8mr25518606igb.79.1356728948782; Fri, 28 Dec 2012 13:09:08 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id lu10sm21531664igc.15.2012.12.28.13.09.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Dec 2012 13:09:07 -0800 (PST) Sender: Warner Losh Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 28 Dec 2012 14:09:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmGHJzB1Q3WHaaR3DH8sqK/QtQPHHf0T+szvjARUEVKkT64tYA+YJxv96gu7JYYrWkuFi6v Cc: David Chisnall , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 21:09:16 -0000 On Dec 28, 2012, at 9:47 AM, Adrian Chadd wrote: > .. the compiler should know the alignment for each of those types and > pad the structure appropriately, right? No, it doesn't. At least traditionally gcc and other compilers will = assume you know what you are doing and use the natural accessors. > david - what's the "right" behaviour here? Surely clang should be > inserting 4 bytes of padding before that pointer? For OABI, no padding is the correct answer. For EABI padding is, I = believe, the right answer. If it matters, and if you are matching an = external standard, be explicit in some way with packed attributes and/or = explicit dummy padding members. Warner >=20 > Adrian >=20 >=20 > On 28 December 2012 08:41, Daisuke Aoyama wrote: >>>>> This is complete version of systimer patch. >>>>> It should fix stopping interrupt and related things such as USB = LAN is >>>>> unstable, >>>>> SSH is closed suddenly. >>>>> (I've not yet finished all test at this time, but at least = portsnap >>>>> fetch is >>>>> success. >>>>> Now extracting the ports without any problems.) >>=20 >>=20 >> Finished without any problems. >>=20 >>=20 >> I'm checking the alignment of clang now. It seems no difference of = location >> of data structure. >> However, access method is different. >>=20 >> I learned clang will combine two loads into one op. >> This is a reason why the alignment seems difference between clang and = gcc. >> Also, a reason why clang binary is smaller than gcc code. >>=20 >> According to ARM manual, strd alignment is: >> "The address must be a multiple of eight for doubleword transfers." >>=20 >> uboot/lib/api_public.h: >> = ---------------------------------------------------------------------- >> struct sys_info { >> unsigned long clk_bus; >> unsigned long clk_cpu; >> unsigned long bar; >> struct mem_region *mr; /* << mr offset is 12!! (not DW >> aligned) */ >> int mr_no; /* number of memory regions */ >> }; >>=20 >> uboot/lib/glue.c: >> = ---------------------------------------------------------------------- >> struct sys_info * >> ub_get_sys_info(void) >> { >> int err =3D 0; >>=20 >> memset(&si, 0, sizeof(struct sys_info)); >> si.mr =3D mr; >> si.mr_no =3D UB_MAX_MR; >> memset(&mr, 0, sizeof(mr)); >>=20 >> if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) >> return (NULL); >>=20 >> return ((err) ? NULL : &si); >> } >>=20 >> = ---------------------------------------------------------------------- >> clang -O2 output (7 steps): >> bl memset ; ATPCS uses r0-r3 as parameters >> ldr r0, .LCPI6_1 ; mr >> mov r1, #5 ; UB_MAX_MR >> mov r2, #60 ; sizeof(mr) >> strd r0, r1, [r5, #12] ; r5 aligned but strd requires = DW(8byte) >> alignment (faulted here) >> mov r1, #0 >> bl memset ; memset(&mr, 0, sizeof(mr)); >>=20 >> clang final binary size(2.8% smaller): >> -rwxr-xr-x 1 root wheel 235984 Dec 28 23:49 ubldr >> = ---------------------------------------------------------------------- >> gcc 4.2 -O2 output (9 steps): >> bl memset ; ATPCS uses r0-r3 as parameters >> ldr ip, .L162+4 ; mr >> mov r3, #5 ; UB_MAX_MR >> mov r1, r4 ; r4 is zero >> mov r0, ip ; << what?? >> mov r2, #60 ; sizeof(mr) >> str r3, [r6, #16] ; r6 aligned same as clang >> str ip, [r6, #12] ; r6 aligned same as clang >> bl memset ; memset(&mr, 0, sizeof(mr)); >>=20 >> gcc final binary size: >> -rwxr-xr-x 1 root wheel 242810 Dec 28 18:22 ubldr >> = ---------------------------------------------------------------------- >> I don't know gcc 4.3 or newer, but probably output is more smart. >> It seems that there is no reason to use ip in this case. >>=20 >> Does any one know how to prevent above clang output? >> (or how to solve this issue for all codes.) >>=20 >> Thanks >>=20 >> -- >> Daisuke Aoyama >>=20 >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"