This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: AArch64 ILP32 abi in glibc
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Catalin Marinas <catalin dot marinas at arm dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Steve Ellcey <sellcey at caviumnetworks dot com>, Andrew Pinski <pinskia at gmail dot com>
- Date: Fri, 7 Jul 2017 11:46:41 -0400
- Subject: Re: AArch64 ILP32 abi in glibc
- Authentication-results: sourceware.org; auth=none
- References: <59553555.3010004@arm.com> <1e2219c7-6ff1-2ba7-d6b0-bbfe84ac2865@redhat.com>
On 07/06/2017 06:07 PM, Florian Weimer wrote:
> On 06/29/2017 07:13 PM, Szabolcs Nagy wrote:
>> On the glibc side the plan is to create an ILP32 branch once the
>> known glibc and kernel side issues are resolved. This way we have
>> a canonical upstream branch for all ILP32 activity and we would
>> like downstream consumers to use this branch. Contributions to
>> this branch should go through the libc-alpha review process like
>> for master and I expect interested parties including Cavium to
>> help maintaining the branch.
>
> I'm worried that the existence of such a branch will interact poorly
> with cleanups in master, say if some baroque constructs aren't needed
> anymore by any supported port, but ILP32 happens to benefit from it. In
> some cases, the branch might get away with not merging the cleanup, but
> in others, the ripple-on effect might be too severe.
As ILP32 is not on master, the port will need to adjust to any changes
we make, not the other way around.
I expect Szabolcs and other to act professionally in this regard, and
not block positive changes to master because it creates work for the
ILP32 branch.
We should be completely free to make any cleanups we see fit on master
without any significant consideration to ILP32. That doesn't mean that
the ILP32 developers cannot ask for consideration, but they must put
forth a very strong rationale.
--
Cheers,
Carlos.