Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Dec 2012 14:09:04 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        David Chisnall <theraven@freebsd.org>, freebsd-arm@freebsd.org
Subject:   Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
Message-ID:  <F28AB348-B188-4734-80AF-D2DD27DB3073@bsdimp.com>
In-Reply-To: <CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR%2BYRp%2BzGROtS8GcJrCiZA@mail.gmail.com>
References:  <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp> <B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp> <E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com> <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com> <F384770FEB784C67BC89AFF7CF57E96C@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> <CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR%2BYRp%2BzGROtS8GcJrCiZA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <aoyama@peach.ne.jp> 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"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F28AB348-B188-4734-80AF-D2DD27DB3073>