This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH 0/3] bugfix for aarch64 ILP32
- From: Bamvor Jian Zhang <bamvor dot zhangjian at huawei dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "apinski at cavium dot com" <apinski at cavium dot com>, "yangyingliang at huawei dot com" <yangyingliang at huawei dot com>, "bintian dot wang at huawei dot com" <bintian dot wang at huawei dot com>, "dingtianhong at huawei dot com" <dingtianhong at huawei dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Mon, 23 Mar 2015 10:45:22 +0800
- Subject: Re: [RFC PATCH 0/3] bugfix for aarch64 ILP32
- Authentication-results: sourceware.org; auth=none
- References: <1426674611-26427-1-git-send-email-bamvor dot zhangjian at huawei dot com> <550963BF dot 9020704 at arm dot com> <550A5E5B dot 9080300 at huawei dot com> <550AB205 dot 7000402 at arm dot com>
On 2015/3/19 19:24, Szabolcs Nagy wrote:
>
> On 19/03/15 05:27, Bamvor Jian Zhang wrote:
>> There was a patch about change kernel uapi to as same as the arm 32bit
>> version[1]. That patch try to keep the userspace compatabilities. What
>> do you think about it?
>
> using 32bit compat syscalls makes sense, but i dont know all the
> kernel side consequences (eg if compat syscall abi is compatible
> with non-compat one)
For msgsnd and msgrcv, the only common variable is between them and other
IPC syscall(e.g. msgctl) is msgid which is int(32bit) in both compat and
normal syscalls. So, It seems that it will not break something.
>> Besides, there is a off_t relative fix in LTP testsuite[2] which is
>> fix sizeof(off_t) changes in application. And use 64bit off_t could
>> make use of the normal syscall instead of the compat one. It seems that
>> it worth to change.
>
> the assumption in the ltp testsuite that size_t is same sized as off_t
> is clearly broken and should be fixed
>
> (ltp was probably only used with 32bit off_t on 32bit systems so far..)
>
>> Understand, I want to do something to see if we could speed up ilp32
>> upstreaming.
>
> well the kernel side issues should be sorted out first (which seems
> to be a hard problem because timespec is everywhere) or you will
> end up with a broken ilp32 abi
>
>> [1] https://sourceware.org/ml/libc-alpha/2015-03/msg00579.html
>> [2] http://sourceforge.net/p/ltp/mailman/ltp-list/thread/1426742198-17967-3-git-send-email-bamvor.zhangjian%40huawei.com/#msg33613776
>>
>>
>>
>
>
> .
>