This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: AArch64 ILP32 abi in glibc
- From: Florian Weimer <fweimer at redhat dot com>
- To: 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>, Carlos O'Donell <carlos at redhat 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 00:07:14 +0200
- Subject: Re: AArch64 ILP32 abi in glibc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9DF387F40E
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9DF387F40E
- References: <59553555.3010004@arm.com>
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.
Can we do without a branch instead? I don't see how things are simpler
for non-ILP32 developers without the branch. I expected that I'll deal
with fallout on ILP32 like I deal with other not-exactly-mainstream
architectures, and the separate branch makes that harder.
Thanks,
Florian