FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
Warner Losh
imp at bsdimp.com
Fri Dec 28 21:09:16 UTC 2012
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
>
> Adrian
>
>
> On 28 December 2012 08:41, Daisuke Aoyama <aoyama at 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.)
>>
>>
>> Finished without any problems.
>>
>>
>> I'm checking the alignment of clang now. It seems no difference of location
>> of data structure.
>> However, access method is different.
>>
>> 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.
>>
>> According to ARM manual, strd alignment is:
>> "The address must be a multiple of eight for doubleword transfers."
>>
>> 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 */
>> };
>>
>> uboot/lib/glue.c:
>> ----------------------------------------------------------------------
>> struct sys_info *
>> ub_get_sys_info(void)
>> {
>> int err = 0;
>>
>> memset(&si, 0, sizeof(struct sys_info));
>> si.mr = mr;
>> si.mr_no = UB_MAX_MR;
>> memset(&mr, 0, sizeof(mr));
>>
>> if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si))
>> return (NULL);
>>
>> return ((err) ? NULL : &si);
>> }
>>
>> ----------------------------------------------------------------------
>> 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));
>>
>> 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));
>>
>> 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.
>>
>> Does any one know how to prevent above clang output?
>> (or how to solve this issue for all codes.)
>>
>> Thanks
>>
>> --
>> Daisuke Aoyama
>>
>>
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
More information about the freebsd-arm
mailing list