Message ID | 1466770980-18933-1-git-send-email-ynorov@caviumnetworks.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 101699 invoked by alias); 24 Jun 2016 12:23:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 101682 invoked by uid 89); 24 Jun 2016 12:23:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HTo:D*gentoo.org, 35, 5, 20, 8 X-HELO: na01-bl2-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; From: Yury Norov <ynorov@caviumnetworks.com> To: <libc-alpha@sourceware.org>, <vapier@gentoo.org>, <joseph@codesourcery.com> CC: <cmetcalf@tilera.com>, <pinskia@gmail.com>, <cmetcalf@mellanox.com>, Yury Norov <ynorov@caviumnetworks.com> Subject: [PATCH] off_t: fix register pair calculation for 64-bit case Date: Fri, 24 Jun 2016 15:23:00 +0300 Message-ID: <1466770980-18933-1-git-send-email-ynorov@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: HE1PR01CA0053.eurprd01.prod.exchangelabs.com (10.165.170.149) To DM3PR07MB2252.namprd07.prod.outlook.com (10.164.33.150) X-MS-Office365-Filtering-Correlation-Id: 600def00-99ae-44b1-0cf0-08d39c2a5118 X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 2:5vCvFYr5bERcp0qy2aZt1Ffa6J3pl84n6j6x1Z2OV7xSz52qS3YewAsoMQqd1hkbQeDYCYm5VI+nQh0Ls38JjhfyIcJDgL+OFOkFs8nFZvCWiONxzJgVFpHEWvlOnJEpCnWlqSC3UvEmY1UojejvbbTyBP68/4lUy2iLXZZkx/3KeQRvq9G2zxQdQdlXexAr; 3:kFXXH2m8Nf3uGRAam3KKesjf8s9PbtKddeskrm6307yS1xbbL6n7yqj/onx0eVqfvqKrBGak9Rre4lphIFHENsbyKsxNWXlUTDooUpDNpGCTmO5mdPtvO0EKbyK6iR4X; 25:V/ZRWI/ZkfKxRD1aj7uyljQJKK6uuHFrxtkGnmZKyM1DTQEHMxcew210gm4S/3jLLfKNAFeyJjkXGME+AI77SSG0jFhfZKSUqllPpeHEoLEhgYiPq/RFqAA4mqmsx8G/sXTFg8FCENzKESn8I1Y87IkyMjTL6oyhi3goImL6lncqhH0MYZa8yVrz8mC1gXjcIoFGiI2/bbVijwQhWk6dRi3EzTt472q+dw4j1zCy/6NL9Y8GKmdN1sCoy/k7v38OMtQZnR5UO4INB+1Pb2gDDz6srKR5HVPPFWbb4VBXJejOE3lAWMZQUrIsCJfDUgwBIFzb6Jlm20v6YdGG0qoX1UDetzQfEYBRtGSFi/XaVtkDmUM4ZfKFht3Mmjtf5qKYz5AFBhPC8P4nfTdcFUrol4rLfSd/TCct91hypNrT+As= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 20:RcrvRaQ53/RaGoZF1yJSdJaskdjxZ7q3XAlfIlavdRd8AfPucduAAxfxQRqwRevsyKVD5mUB6JAJWVsSGO2eE9TIMKmieRQGFKD483/ZM94PnMi/vzUcWCqppHqGrE9/aSou29qxKfaXmmFnU8Q8Da7+fROj50atEeqz/WetHvoF6RrQsat49mgVAxQ7yVTzauHjV6Xb5/4vpD1wgIe+9HaGj/ciVYwnos+Jb7MVCZek03ELwnnTp3qwelyZVErZo0HQNewuPBPvxYBUpOYh70a3gzlH/bvPqxR3PsVOvxaalWaHMnCLlTw6ARmcgSnwkCji98B12P35srvVvbmPAWfVZ7x6dzUQ/HQ7D4RsoaMsQYPY6zUF58dms72XDKTZWgKvZZB1Zbp+j8P1+fqv4a1y5tl0xU6VtAlIhob4XFJaFnzS4+tdYUOkfHmdyyfXzduscrdj8pQ3TADvHK0+qEcxAyuEbMpTP/pR+ndQs68A52Ta9ISrKUJr6D3qzbzBmSGYubkNhbasVbgjfh8jbCMGyVumQlNGEAiLOY6VVxqzBtZ9nFKOlgHVYketTmXbM0T3vT553r7Qlqsg6vVQvRhUWKWBScZP4Nuhl3n6I8U= X-Microsoft-Antispam-PRVS: <DM3PR07MB2252044C632952FAF8F1DD8EEE2E0@DM3PR07MB2252.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM3PR07MB2252; BCL:0; PCL:0; RULEID:; SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 4:2ZIB8XmobxhOTkvV32c6AMuGHZWoTt9CcF/95lR23mlUn+rOTW5Daiu4NYutU3NbF3mwUIPNPlWYSsY1ioYv02wOUotB5shB40zdlR6jlQStMUN6i7ZfMSFXt8inmgEo7Q+qOi2fzoCUS4accgMBEaPp8bpaBXtuF31S+TxbhnxTKYUtZiPG3R+rm7i2JclAUOiLcEC9c5c7DgvW/f6RjACNPuPR0tpDSO65CPTwRo3g3V05uEFRwG/tE/1X7kDQK7LWbrrE+GvwvO8mRr49Tvwg+FAAyRr+QVJt4sok/N4GqZ4S61Lk89uZklYjduy+joqyCRKSMll368JmhqfV11pxcAyVrinjUKz69s5cJjhjKcf0+Iwql51lt+KAfXX9 X-Forefront-PRVS: 0983EAD6B2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(199003)(189002)(5003940100001)(50986999)(97736004)(4001430100002)(5001770100001)(3846002)(6116002)(189998001)(586003)(7846002)(81156014)(7736002)(92566002)(68736007)(81166006)(305945005)(50226002)(77096005)(19580405001)(19580395003)(2906002)(76506005)(229853001)(33646002)(575784001)(47776003)(105586002)(106356001)(42186005)(8676002)(66066001)(50466002)(48376002)(107886002)(101416001)(36756003)(4326007)(2201001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM3PR07MB2252; H:localhost; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM3PR07MB2252; 23:zlZj/Sv8uWgfgmZh6W2Uwjgv886q2FUQvO5dRn8Tm?= =?us-ascii?Q?1FKRnkuRbMuUuvCQUu9mGVgUMFVoqjSJ24l8Qlvbtyju/zu5MwyqgmuNL1o8?= =?us-ascii?Q?+K9ZRvWdYPAjM8svZDLl6qePbm+4snI5vWJlhAYqWSjUoBAJpXGCl8giW7dF?= =?us-ascii?Q?JPausXjkL6LQuj2o/s2RawpngppZUAFMmSucA6uFzCm7NT0djuvplNcbihzj?= =?us-ascii?Q?SA5oWySksi4AGqqXhAX53YVEgYpFjGvxY3fCWIOmR0bJ9NwtVvB8f5rNuw9a?= =?us-ascii?Q?vpyJzb0iH+XGUa2/9h0EfaSXiTVXHK2FShYyT1IdfJRVFXDlYVXZBK0dSxxb?= =?us-ascii?Q?GvbDp5I4cHjfPPbCWDmdlHhZ/pwIz/9GWIFCGyQDZRBp1nNLYNZTWXb0L+Z8?= =?us-ascii?Q?PGVtV4GoBzKL1NCfMSV4ykOgN/OPf9kQCpOoZKAmRLcBRYYwp2cVgSWujWla?= =?us-ascii?Q?6Ar8xUQOG69j4+b35aCYIlIMhxd+xmZX3xdbzl1mbSR/nGAgCyL+Gu1nCslE?= =?us-ascii?Q?Tl1H6/x39WL3MyXiVejB3U3gxAK+MPu4dQNhUNnBQDMlceS1iF6PfkRmt3cJ?= =?us-ascii?Q?DugNRPj2JOR4rb9k+giAO6O/VyyzAhk8kra7ExChCKJa+CCIMFUrevWAv4an?= =?us-ascii?Q?jMttPVCajluPqLS6QkcyNVJHwTPCF3tzqcqdfDx9xESpkVPHQX3otPKqpigL?= =?us-ascii?Q?1jgZcPbG2R4wGbK2TpGH1nJKcR/VKBtUx7WbPb8aPHiaKLz85piEZ0g4DKyQ?= =?us-ascii?Q?qGUDqGbANZDRwFMPQ4s2D4tRdCLPcxIcNrVAhCDzqrWXeWZwN7dofmrx2GnK?= =?us-ascii?Q?jifi0h01TkKNN0wnXrO7gw1nF0ZTgaqpRsD1fWkvMBMAFZukA1bQw+6ZrHg7?= =?us-ascii?Q?ur0sdHVVfPLkCQpmUBuBfhenUkazh8FqcOLf5KqqMtOm5SVC5bwlTWSude5S?= =?us-ascii?Q?7tkTp7pMlrm0aq0pOX3JCsNvAwQcNMCplTaJtOUo5VDMUoX51DOUK9NqNYMt?= =?us-ascii?Q?oMb7Efwx4vA/xX1/vZTSp6RtiyP+aRiqNIyGLsVOABisjTVGpQ46SQ8ncPPN?= =?us-ascii?Q?VFEWg3x0sNi5OcLatwlhNy1EZ/BT4MKBRusHk4dyQgnNMekbt4G4LZ6yIGYl?= =?us-ascii?Q?6cIInUtOpc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2252; 6:Awmulz02jnpQVTXgJ6C20t0+95Jo0AHNBu5qSY3DBKHv6JOHXr8QJCDP8Fdwo5+bvjimPyPMpCW9qXfXfe7jTFog0xbkmRJvta5mIpQAWmPq2aXoMUjmadG/1V1TaAaY2lgRuWOTbBoeHP5PmeoH1Tx5WCLbWnyffDZa/JPU++PnZQDwLmjgzFOc9yNrLZC07q5kmcsuJ5M5uPQsaoHnxW02cbyxvUhxuqfDs0z80zT5N3Z1doSVfL1lRPnYynEjH4GUQv52fcJw6j43d1LafAJtoMNM/Abx/mUKJojGizUP7FzoTArEP7Rd4Yop7laH; 5:jx95w5Ctl+2nI3bgTQDlIF4yjCjNciVKRe7B78S+YCAWDzV/0wqqs+fXqRWW3oNkJDLZbc8g6M820QxNjlZmHSy3TXwJ+W5UDiI2JjQxqmnjwfPLZNvP3wrg+W5mWXWbI/l9SNBE1wkM3XoBSLL7WA==; 24:tT41B9Zj1DxAVu+2f+jSOMkGKI0xKVHu06uv0jh9xEH3uMZhxSX+CkoU8t3EI9xc9Bix63JaUpSfRZsbmKdOtXisJE5FPTRJ/oJJVbO08zQ=; 7:9gG3wSswVHLPH0JcwqNpvs2EtAt9eORLIMHeeof+eAwUXnTbKCOK6ANVzrBzOoUTYYZPVaqO34AbmxwTivmEYQ68+5uKNXZPsdvYn1xPco2blCDw5Hg34zfENp2Qdm7mmdFszqzWqUt7W39Ex6FDZgQ3KHYrHxk6HaDzBpd6cLgRWpsCV74f0FSVlqFLzzIEITeCHRQxRa2+XlD4FOO3LpL3d/RkApA+P8uDcPoh3+fIJK3TNKNG2EQm+4Vf6KjG3E42jgxAowbT5Y+IuiExqg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2016 12:23:14.7387 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR07MB2252 |
Commit Message
Yury Norov
June 24, 2016, 12:23 p.m. UTC
There are 3 syscall wrappers under sysdeps/unix/sysv/linux that
calculate register pair for off_t like this:
__LONG_LONG_PAIR (offset >> 31, offset)
While it works for 32-bit off_t, new 32-bit APIs that use 64-bit
off_t will be broken with it. This patch redirects affected syscalls
to their 64-bit versions. It also saves few instructions and symbols
in glibc, as 32-bit syscall wrappers are not generated anymore.
Tested on AARCH64/ILP32.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
sysdeps/unix/sysv/linux/fallocate.c | 4 ++++
sysdeps/unix/sysv/linux/fallocate64.c | 4 ++++
sysdeps/unix/sysv/linux/posix_fadvise.c | 4 ++++
sysdeps/unix/sysv/linux/posix_fadvise64.c | 4 ++++
sysdeps/unix/sysv/linux/posix_fallocate.c | 4 ++++
sysdeps/unix/sysv/linux/posix_fallocate64.c | 4 ++++
6 files changed, 24 insertions(+)
Comments
On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > There are 3 syscall wrappers under sysdeps/unix/sysv/linux that > calculate register pair for off_t like this: > __LONG_LONG_PAIR (offset >> 31, offset) > > While it works for 32-bit off_t, new 32-bit APIs that use 64-bit > off_t will be broken with it. This patch redirects affected syscalls > to their 64-bit versions. It also saves few instructions and symbols > in glibc, as 32-bit syscall wrappers are not generated anymore. If you have 64-bit register, should you use wordsize-64, like sysdeps/unix/sysv/linux/wordsize-64 H.J.
On Fri, Jun 24, 2016 at 05:30:32AM -0700, H.J. Lu wrote: > On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > There are 3 syscall wrappers under sysdeps/unix/sysv/linux that > > calculate register pair for off_t like this: > > __LONG_LONG_PAIR (offset >> 31, offset) > > > > While it works for 32-bit off_t, new 32-bit APIs that use 64-bit > > off_t will be broken with it. This patch redirects affected syscalls > > to their 64-bit versions. It also saves few instructions and symbols > > in glibc, as 32-bit syscall wrappers are not generated anymore. > > If you have 64-bit register, should you use wordsize-64, like > > sysdeps/unix/sysv/linux/wordsize-64 > > H.J. Sometimes it's not possible. AARCh64/ILP32 requires to pass 64-bit parameters as pair. (this is one of two options for ILP32 that is under discussion)
On Fri, Jun 24, 2016 at 5:41 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > On Fri, Jun 24, 2016 at 05:30:32AM -0700, H.J. Lu wrote: >> On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: >> > There are 3 syscall wrappers under sysdeps/unix/sysv/linux that >> > calculate register pair for off_t like this: >> > __LONG_LONG_PAIR (offset >> 31, offset) >> > >> > While it works for 32-bit off_t, new 32-bit APIs that use 64-bit >> > off_t will be broken with it. This patch redirects affected syscalls >> > to their 64-bit versions. It also saves few instructions and symbols >> > in glibc, as 32-bit syscall wrappers are not generated anymore. >> >> If you have 64-bit register, should you use wordsize-64, like >> >> sysdeps/unix/sysv/linux/wordsize-64 >> >> H.J. > > Sometimes it's not possible. AARCh64/ILP32 requires to pass 64-bit > parameters as pair. (this is one of two options for ILP32 that is > under discussion) You should still use wordsize-64 and make special exceptions if needed.
On Friday, June 24, 2016 5:57:26 AM CEST H.J. Lu wrote: > On Fri, Jun 24, 2016 at 5:41 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > On Fri, Jun 24, 2016 at 05:30:32AM -0700, H.J. Lu wrote: > >> On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > >> > There are 3 syscall wrappers under sysdeps/unix/sysv/linux that > >> > calculate register pair for off_t like this: > >> > __LONG_LONG_PAIR (offset >> 31, offset) > >> > > >> > While it works for 32-bit off_t, new 32-bit APIs that use 64-bit > >> > off_t will be broken with it. This patch redirects affected syscalls > >> > to their 64-bit versions. It also saves few instructions and symbols > >> > in glibc, as 32-bit syscall wrappers are not generated anymore. > >> > >> If you have 64-bit register, should you use wordsize-64, like > >> > >> sysdeps/unix/sysv/linux/wordsize-64 > >> > >> H.J. > > > > Sometimes it's not possible. AARCh64/ILP32 requires to pass 64-bit > > parameters as pair. (this is one of two options for ILP32 that is > > under discussion) > > You should still use wordsize-64 and make special exceptions if needed. Can the syscall ABI be a single exception then? I think at this point the syscall interface for aarch64 ILP32 is exactly the same as for 32-bit RISC-V. I guess it makes sense to use sysdeps/wordsize-64/ and sysdeps/ieee754/dbl-64/wordsize-64/, but the sysdeps/unix/sysv/linux/wordsize-64/ directory seems to only contain files for syscalls that differ between 32-bit and 64-bit architectures, so each one of them would otherwise need a separate override that redirects to the normal 32-bit syscall. Arnd
On Fri, Jun 24, 2016 at 03:15:50PM +0200, Arnd Bergmann wrote: > On Friday, June 24, 2016 5:57:26 AM CEST H.J. Lu wrote: > > On Fri, Jun 24, 2016 at 5:41 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > > On Fri, Jun 24, 2016 at 05:30:32AM -0700, H.J. Lu wrote: > > >> On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > >> > There are 3 syscall wrappers under sysdeps/unix/sysv/linux that > > >> > calculate register pair for off_t like this: > > >> > __LONG_LONG_PAIR (offset >> 31, offset) > > >> > > > >> > While it works for 32-bit off_t, new 32-bit APIs that use 64-bit > > >> > off_t will be broken with it. This patch redirects affected syscalls > > >> > to their 64-bit versions. It also saves few instructions and symbols > > >> > in glibc, as 32-bit syscall wrappers are not generated anymore. > > >> > > >> If you have 64-bit register, should you use wordsize-64, like > > >> > > >> sysdeps/unix/sysv/linux/wordsize-64 > > >> > > >> H.J. > > > > > > Sometimes it's not possible. AARCh64/ILP32 requires to pass 64-bit > > > parameters as pair. (this is one of two options for ILP32 that is > > > under discussion) > > > > You should still use wordsize-64 and make special exceptions if needed. > > Can the syscall ABI be a single exception then? I think at this > point the syscall interface for aarch64 ILP32 is exactly the same > as for 32-bit RISC-V. > > I guess it makes sense to use sysdeps/wordsize-64/ and > sysdeps/ieee754/dbl-64/wordsize-64/, but the > sysdeps/unix/sysv/linux/wordsize-64/ directory seems to only > contain files for syscalls that differ between 32-bit and > 64-bit architectures, so each one of them would otherwise > need a separate override that redirects to the normal 32-bit > syscall. > > Arnd > Hi Arnd, H.J. Lu, others, I'm not so experienced in the glibc, and it seems I lost your point. The whole idea of ILP32 patchset is to be a counterpart for kernel code that clears top halves of registers unconditionally at now. It means we cannot pass any 64-bit value in a single register, and that's what the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't understand how we can use it. Regarding this patch. As far as I understand, each ABI can define size of it's types with no relation to register size. And modern 32-bit ABIs should have off_t, ino_t etc 64-bit. So we have off_t 64-bit but pass it in a pair. That's what the code under sysdeps/unix/sysv/linux/ does, except that it does not do it right. I didn't find the limitation on sysdeps/unix/sysv/linux/ to have off_t exactly 32-bit, and it means it should work correct for both cases. And therefore my patch fixes real bug. In other hand, if sysdeps/unix/sysv/linux/ should work with 32-bit off_t only, I suggest to describe it explicitly with code like this: #ifdef __OFF_T_MATCHES_OFF64_T # error off_t is 32-bit only #endif where needed. But then I'll still have to use sysdeps/unix/sysv/linux/ for ILP32, and will redirect off_t-related syscalls in platform code. Yury
On Monday, June 27, 2016 9:26:46 AM CEST Yury Norov wrote: > On Fri, Jun 24, 2016 at 03:15:50PM +0200, Arnd Bergmann wrote: > > On Friday, June 24, 2016 5:57:26 AM CEST H.J. Lu wrote: > > > On Fri, Jun 24, 2016 at 5:41 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > > > On Fri, Jun 24, 2016 at 05:30:32AM -0700, H.J. Lu wrote: > > > >> On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > > >> > There are 3 syscall wrappers under sysdeps/unix/sysv/linux that > > > >> > calculate register pair for off_t like this: > > > >> > __LONG_LONG_PAIR (offset >> 31, offset) > > > >> > > > > >> > While it works for 32-bit off_t, new 32-bit APIs that use 64-bit > > > >> > off_t will be broken with it. This patch redirects affected syscalls > > > >> > to their 64-bit versions. It also saves few instructions and symbols > > > >> > in glibc, as 32-bit syscall wrappers are not generated anymore. > > > >> > > > >> If you have 64-bit register, should you use wordsize-64, like > > > >> > > > >> sysdeps/unix/sysv/linux/wordsize-64 > > > >> > > > >> H.J. > > > > > > > > Sometimes it's not possible. AARCh64/ILP32 requires to pass 64-bit > > > > parameters as pair. (this is one of two options for ILP32 that is > > > > under discussion) > > > > > > You should still use wordsize-64 and make special exceptions if needed. > > > > Can the syscall ABI be a single exception then? I think at this > > point the syscall interface for aarch64 ILP32 is exactly the same > > as for 32-bit RISC-V. > > > > I guess it makes sense to use sysdeps/wordsize-64/ and > > sysdeps/ieee754/dbl-64/wordsize-64/, but the > > sysdeps/unix/sysv/linux/wordsize-64/ directory seems to only > > contain files for syscalls that differ between 32-bit and > > 64-bit architectures, so each one of them would otherwise > > need a separate override that redirects to the normal 32-bit > > syscall. > > > Hi Arnd, H.J. Lu, others, > > I'm not so experienced in the glibc, and it seems I lost your point. I'm also not very experienced in glibc, it's possible that I'm the one who's confused > The whole idea of ILP32 patchset is to be a counterpart for kernel code > that clears top halves of registers unconditionally at now. It means we > cannot pass any 64-bit value in a single register, and that's what > the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't > understand how we can use it. The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for the 64-bit syscall API, which is not appropriate here as the kernel port uses the 32-bit syscall API, now basically unchanged. This is the same as tile64/ilp32 does, but different from x86-64/ilp32 (x32). > Regarding this patch. As far as I understand, each ABI can define size > of it's types with no relation to register size. And modern > 32-bit ABIs should have off_t, ino_t etc 64-bit. So we have off_t > 64-bit but pass it in a pair. That's what the code under > sysdeps/unix/sysv/linux/ does, except that it does not do it right. > > I didn't find the limitation on sysdeps/unix/sysv/linux/ to have off_t > exactly 32-bit, and it means it should work correct for both cases. > And therefore my patch fixes real bug. > > In other hand, if sysdeps/unix/sysv/linux/ should work with 32-bit > off_t only, I suggest to describe it explicitly with code like this: > > #ifdef __OFF_T_MATCHES_OFF64_T > # error off_t is 32-bit only > #endif > > where needed. But then I'll still have to use sysdeps/unix/sysv/linux/ > for ILP32, and will redirect off_t-related syscalls in platform code. I agree your patch looks fine, and it fixes the problem for 32-bit RISC-V as well. Redirecting off_t based syscalls to architecture specific code sounds wrong: We should do the same thing for aarch64/ilp32 and 32-bit risc-v, whatever we end up doing. The alternative that I think Mike Frysinger was hinting at would be to leave off_t as 32-bit even on aarch64/ilp32, but then just not use it. If you build your compiler to always pass _FILE_OFFSET_BITS=64, you can leave this part of glibc completely untouched and will get the symbols for handling 32-bit off_t, but all applications built against the libc will use 64-bit off_t anyway. To me, that sounds like a bigger hack for the whole system, but it makes the glibc platform specific code a bit simpler because we avoid the special case. Arnd
On 27/06/2016 06:08, Arnd Bergmann wrote: > On Monday, June 27, 2016 9:26:46 AM CEST Yury Norov wrote: >> On Fri, Jun 24, 2016 at 03:15:50PM +0200, Arnd Bergmann wrote: >>> On Friday, June 24, 2016 5:57:26 AM CEST H.J. Lu wrote: >>>> On Fri, Jun 24, 2016 at 5:41 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: >>>>> On Fri, Jun 24, 2016 at 05:30:32AM -0700, H.J. Lu wrote: >>>>>> On Fri, Jun 24, 2016 at 5:23 AM, Yury Norov <ynorov@caviumnetworks.com> wrote: >>>>>>> There are 3 syscall wrappers under sysdeps/unix/sysv/linux that >>>>>>> calculate register pair for off_t like this: >>>>>>> __LONG_LONG_PAIR (offset >> 31, offset) >>>>>>> >>>>>>> While it works for 32-bit off_t, new 32-bit APIs that use 64-bit >>>>>>> off_t will be broken with it. This patch redirects affected syscalls >>>>>>> to their 64-bit versions. It also saves few instructions and symbols >>>>>>> in glibc, as 32-bit syscall wrappers are not generated anymore. >>>>>> >>>>>> If you have 64-bit register, should you use wordsize-64, like >>>>>> >>>>>> sysdeps/unix/sysv/linux/wordsize-64 >>>>>> >>>>>> H.J. >>>>> >>>>> Sometimes it's not possible. AARCh64/ILP32 requires to pass 64-bit >>>>> parameters as pair. (this is one of two options for ILP32 that is >>>>> under discussion) >>>> >>>> You should still use wordsize-64 and make special exceptions if needed. >>> >>> Can the syscall ABI be a single exception then? I think at this >>> point the syscall interface for aarch64 ILP32 is exactly the same >>> as for 32-bit RISC-V. >>> >>> I guess it makes sense to use sysdeps/wordsize-64/ and >>> sysdeps/ieee754/dbl-64/wordsize-64/, but the >>> sysdeps/unix/sysv/linux/wordsize-64/ directory seems to only >>> contain files for syscalls that differ between 32-bit and >>> 64-bit architectures, so each one of them would otherwise >>> need a separate override that redirects to the normal 32-bit >>> syscall. >>> >> Hi Arnd, H.J. Lu, others, >> >> I'm not so experienced in the glibc, and it seems I lost your point. > > I'm also not very experienced in glibc, it's possible that I'm the > one who's confused > >> The whole idea of ILP32 patchset is to be a counterpart for kernel code >> that clears top halves of registers unconditionally at now. It means we >> cannot pass any 64-bit value in a single register, and that's what >> the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't >> understand how we can use it. > > The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for > the 64-bit syscall API, which is not appropriate here as the kernel > port uses the 32-bit syscall API, now basically unchanged. > > This is the same as tile64/ilp32 does, but different from x86-64/ilp32 > (x32). I intend to send a patch upstream to consolidate all the fallocate implementation to help this very issue. The idea is to use the same pread consolidate idea: 1. Each architecture/ABI defines if its a ILP32 (__ASSUME_WORDSIZE64_ILP32) and if off64_t differs in size of off_t (__ASSUME_OFF_DIFF_OFF64). Currently, x32 defines __ASSUME_WORDSIZE64_ILP32 and only MIPS64-n32 defines both __ASSUME_WORDSIZE64_ILP32 and __ASSUME_OFF_DIFF_OFF64. 2. For the default function implementation (without the 64 suffix) the symbol will be built if is 32-bits (__WORDSIZE==64) or if off_t differs in size from off64_t (__ASSUME_OFF_DIFF_OFF64). It means that for architecture that only pass 64-bit off_t this symbol won't be build. 3. The 64 variant of the function implementation (with the 64 suffix) will be always build and a weak alias for the non-suffix variant will be created if __WORDSIZE == 64 and if size of off64_t differs from off_t. It means that for architecture that only pass 64-bits off_t function will be an alias to function64. I think with this patch there is no need to more arch-specific implementation. > >> Regarding this patch. As far as I understand, each ABI can define size >> of it's types with no relation to register size. And modern >> 32-bit ABIs should have off_t, ino_t etc 64-bit. So we have off_t >> 64-bit but pass it in a pair. That's what the code under >> sysdeps/unix/sysv/linux/ does, except that it does not do it right. >> >> I didn't find the limitation on sysdeps/unix/sysv/linux/ to have off_t >> exactly 32-bit, and it means it should work correct for both cases. >> And therefore my patch fixes real bug. >> >> In other hand, if sysdeps/unix/sysv/linux/ should work with 32-bit >> off_t only, I suggest to describe it explicitly with code like this: >> >> #ifdef __OFF_T_MATCHES_OFF64_T >> # error off_t is 32-bit only >> #endif >> >> where needed. But then I'll still have to use sysdeps/unix/sysv/linux/ >> for ILP32, and will redirect off_t-related syscalls in platform code. > > I agree your patch looks fine, and it fixes the problem for 32-bit > RISC-V as well. I think this patch is incomplete: it should use the SYSCALL_LL{64} macros for passing off_t{64} arguments which is being used in p{read,write}. I will send a consolidation patch today. > > Redirecting off_t based syscalls to architecture specific code sounds > wrong: We should do the same thing for aarch64/ilp32 and 32-bit > risc-v, whatever we end up doing. The alternative that I think > Mike Frysinger was hinting at would be to leave off_t as 32-bit even > on aarch64/ilp32, but then just not use it. If you build your compiler > to always pass _FILE_OFFSET_BITS=64, you can leave this part of > glibc completely untouched and will get the symbols for handling > 32-bit off_t, but all applications built against the libc will > use 64-bit off_t anyway. To me, that sounds like a bigger hack > for the whole system, but it makes the glibc platform specific code > a bit simpler because we avoid the special case. > > Arnd >
On Monday, June 27, 2016 9:11:51 AM CEST Adhemerval Zanella wrote: > > > >> The whole idea of ILP32 patchset is to be a counterpart for kernel code > >> that clears top halves of registers unconditionally at now. It means we > >> cannot pass any 64-bit value in a single register, and that's what > >> the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't > >> understand how we can use it. > > > > The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for > > the 64-bit syscall API, which is not appropriate here as the kernel > > port uses the 32-bit syscall API, now basically unchanged. > > > > This is the same as tile64/ilp32 does, but different from x86-64/ilp32 > > (x32). > > I intend to send a patch upstream to consolidate all the fallocate > implementation to help this very issue. The idea is to use the same > pread consolidate idea: > > 1. Each architecture/ABI defines if its a ILP32 (__ASSUME_WORDSIZE64_ILP32) > and if off64_t differs in size of off_t (__ASSUME_OFF_DIFF_OFF64). > Currently, x32 defines __ASSUME_WORDSIZE64_ILP32 and only MIPS64-n32 > defines both __ASSUME_WORDSIZE64_ILP32 and __ASSUME_OFF_DIFF_OFF64. > > 2. For the default function implementation (without the 64 suffix) > the symbol will be built if is 32-bits (__WORDSIZE==64) or > if off_t differs in size from off64_t (__ASSUME_OFF_DIFF_OFF64). > > It means that for architecture that only pass 64-bit off_t this > symbol won't be build. > > 3. The 64 variant of the function implementation (with the 64 suffix) > will be always build and a weak alias for the non-suffix variant > will be created if __WORDSIZE == 64 and if size of off64_t differs > from off_t. > > It means that for architecture that only pass 64-bits off_t > function will be an alias to function64. > > I think with this patch there is no need to more arch-specific implementation. Doesn't that assume that the kernel interface uses 64-bit registers to pass off_t? Yury's patch was specifically for the case where you use two 32-bit registers (or two lower halves of 64-bit registers in case of aarch64) but still want 64-bit off_t by default, i.e. (!defined(__ASSUME_WORDSIZE64_ILP32) && !defined(__ASSUME_OFF_DIFF_OFF64)). Arnd
On 27/06/2016 18:01, Arnd Bergmann wrote: > On Monday, June 27, 2016 9:11:51 AM CEST Adhemerval Zanella wrote: >>> >>>> The whole idea of ILP32 patchset is to be a counterpart for kernel code >>>> that clears top halves of registers unconditionally at now. It means we >>>> cannot pass any 64-bit value in a single register, and that's what >>>> the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't >>>> understand how we can use it. >>> >>> The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for >>> the 64-bit syscall API, which is not appropriate here as the kernel >>> port uses the 32-bit syscall API, now basically unchanged. >>> >>> This is the same as tile64/ilp32 does, but different from x86-64/ilp32 >>> (x32). >> >> I intend to send a patch upstream to consolidate all the fallocate >> implementation to help this very issue. The idea is to use the same >> pread consolidate idea: >> >> 1. Each architecture/ABI defines if its a ILP32 (__ASSUME_WORDSIZE64_ILP32) >> and if off64_t differs in size of off_t (__ASSUME_OFF_DIFF_OFF64). >> Currently, x32 defines __ASSUME_WORDSIZE64_ILP32 and only MIPS64-n32 >> defines both __ASSUME_WORDSIZE64_ILP32 and __ASSUME_OFF_DIFF_OFF64. >> >> 2. For the default function implementation (without the 64 suffix) >> the symbol will be built if is 32-bits (__WORDSIZE==64) or >> if off_t differs in size from off64_t (__ASSUME_OFF_DIFF_OFF64). >> >> It means that for architecture that only pass 64-bit off_t this >> symbol won't be build. >> >> 3. The 64 variant of the function implementation (with the 64 suffix) >> will be always build and a weak alias for the non-suffix variant >> will be created if __WORDSIZE == 64 and if size of off64_t differs >> from off_t. >> >> It means that for architecture that only pass 64-bits off_t >> function will be an alias to function64. >> >> I think with this patch there is no need to more arch-specific implementation. > > Doesn't that assume that the kernel interface uses 64-bit registers > to pass off_t? Yury's patch was specifically for the case where > you use two 32-bit registers (or two lower halves of 64-bit registers > in case of aarch64) but still want 64-bit off_t by default, > i.e. (!defined(__ASSUME_WORDSIZE64_ILP32) && !defined(__ASSUME_OFF_DIFF_OFF64)). > > Arnd > So if I understood correctly AArch64/ILP32 will another way to handle off_t/off64_t, which indeed the original patch make sense.
On Mon, Jun 27, 2016 at 08:00:41PM -0300, Adhemerval Zanella wrote: > > > On 27/06/2016 18:01, Arnd Bergmann wrote: > > On Monday, June 27, 2016 9:11:51 AM CEST Adhemerval Zanella wrote: > >>> > >>>> The whole idea of ILP32 patchset is to be a counterpart for kernel code > >>>> that clears top halves of registers unconditionally at now. It means we > >>>> cannot pass any 64-bit value in a single register, and that's what > >>>> the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't > >>>> understand how we can use it. > >>> > >>> The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for > >>> the 64-bit syscall API, which is not appropriate here as the kernel > >>> port uses the 32-bit syscall API, now basically unchanged. > >>> > >>> This is the same as tile64/ilp32 does, but different from x86-64/ilp32 > >>> (x32). > >> > >> I intend to send a patch upstream to consolidate all the fallocate > >> implementation to help this very issue. The idea is to use the same > >> pread consolidate idea: > >> > >> 1. Each architecture/ABI defines if its a ILP32 (__ASSUME_WORDSIZE64_ILP32) > >> and if off64_t differs in size of off_t (__ASSUME_OFF_DIFF_OFF64). > >> Currently, x32 defines __ASSUME_WORDSIZE64_ILP32 and only MIPS64-n32 > >> defines both __ASSUME_WORDSIZE64_ILP32 and __ASSUME_OFF_DIFF_OFF64. > >> > >> 2. For the default function implementation (without the 64 suffix) > >> the symbol will be built if is 32-bits (__WORDSIZE==64) or > >> if off_t differs in size from off64_t (__ASSUME_OFF_DIFF_OFF64). > >> > >> It means that for architecture that only pass 64-bit off_t this > >> symbol won't be build. > >> > >> 3. The 64 variant of the function implementation (with the 64 suffix) > >> will be always build and a weak alias for the non-suffix variant > >> will be created if __WORDSIZE == 64 and if size of off64_t differs > >> from off_t. > >> > >> It means that for architecture that only pass 64-bits off_t > >> function will be an alias to function64. > >> > >> I think with this patch there is no need to more arch-specific implementation. > > > > Doesn't that assume that the kernel interface uses 64-bit registers > > to pass off_t? Yury's patch was specifically for the case where > > you use two 32-bit registers (or two lower halves of 64-bit registers > > in case of aarch64) but still want 64-bit off_t by default, > > i.e. (!defined(__ASSUME_WORDSIZE64_ILP32) && !defined(__ASSUME_OFF_DIFF_OFF64)). > > > > Arnd > > > > So if I understood correctly AArch64/ILP32 will another way to handle > off_t/off64_t, which indeed the original patch make sense. Yes. You understood correctly. This is how RISC-V works, and this is default behavior for all new 32-bit ABIs, both native and ILP32. Is my understanding correct that for AARCH64/ILP32, in glibc terms we have solid understanding that __ASSUME_OFF_DIFF_OFF64 is disabled; and__ASSUME_WORDSIZE64_ILP32 depends on kernel wrappers, and under discussion. Could you (someone) explain me the difference between __ASSUME_OFF_DIFF_OFF64 and __OFF_T_MATCHES_OFF64_T? At first glance they are mutual exclusive, and so we can drop one of them. Yury
On 28/06/2016 00:44, Yury Norov wrote: > On Mon, Jun 27, 2016 at 08:00:41PM -0300, Adhemerval Zanella wrote: >> >> >> On 27/06/2016 18:01, Arnd Bergmann wrote: >>> On Monday, June 27, 2016 9:11:51 AM CEST Adhemerval Zanella wrote: >>>>> >>>>>> The whole idea of ILP32 patchset is to be a counterpart for kernel code >>>>>> that clears top halves of registers unconditionally at now. It means we >>>>>> cannot pass any 64-bit value in a single register, and that's what >>>>>> the code under sysdeps/unix/sysv/linux/wordsize-64 does. So I don't >>>>>> understand how we can use it. >>>>> >>>>> The code in sysdeps/unix/sysv/linux/wordsize-64 seems to be made for >>>>> the 64-bit syscall API, which is not appropriate here as the kernel >>>>> port uses the 32-bit syscall API, now basically unchanged. >>>>> >>>>> This is the same as tile64/ilp32 does, but different from x86-64/ilp32 >>>>> (x32). >>>> >>>> I intend to send a patch upstream to consolidate all the fallocate >>>> implementation to help this very issue. The idea is to use the same >>>> pread consolidate idea: >>>> >>>> 1. Each architecture/ABI defines if its a ILP32 (__ASSUME_WORDSIZE64_ILP32) >>>> and if off64_t differs in size of off_t (__ASSUME_OFF_DIFF_OFF64). >>>> Currently, x32 defines __ASSUME_WORDSIZE64_ILP32 and only MIPS64-n32 >>>> defines both __ASSUME_WORDSIZE64_ILP32 and __ASSUME_OFF_DIFF_OFF64. >>>> >>>> 2. For the default function implementation (without the 64 suffix) >>>> the symbol will be built if is 32-bits (__WORDSIZE==64) or >>>> if off_t differs in size from off64_t (__ASSUME_OFF_DIFF_OFF64). >>>> >>>> It means that for architecture that only pass 64-bit off_t this >>>> symbol won't be build. >>>> >>>> 3. The 64 variant of the function implementation (with the 64 suffix) >>>> will be always build and a weak alias for the non-suffix variant >>>> will be created if __WORDSIZE == 64 and if size of off64_t differs >>>> from off_t. >>>> >>>> It means that for architecture that only pass 64-bits off_t >>>> function will be an alias to function64. >>>> >>>> I think with this patch there is no need to more arch-specific implementation. >>> >>> Doesn't that assume that the kernel interface uses 64-bit registers >>> to pass off_t? Yury's patch was specifically for the case where >>> you use two 32-bit registers (or two lower halves of 64-bit registers >>> in case of aarch64) but still want 64-bit off_t by default, >>> i.e. (!defined(__ASSUME_WORDSIZE64_ILP32) && !defined(__ASSUME_OFF_DIFF_OFF64)). >>> >>> Arnd >>> >> >> So if I understood correctly AArch64/ILP32 will another way to handle >> off_t/off64_t, which indeed the original patch make sense. > > Yes. You understood correctly. This is how RISC-V works, and this is > default behavior for all new 32-bit ABIs, both native and ILP32. > > Is my understanding correct that for AARCH64/ILP32, in glibc terms > we have solid understanding that __ASSUME_OFF_DIFF_OFF64 is disabled; > and__ASSUME_WORDSIZE64_ILP32 depends on kernel wrappers, and under > discussion. > > Could you (someone) explain me the difference between > __ASSUME_OFF_DIFF_OFF64 and __OFF_T_MATCHES_OFF64_T? > At first glance they are mutual exclusive, and so we > can drop one of them. I see they are essentially the same and I added __ASSUME_OFF_DIFF_OFF64 on my pread consolidation by two main reasons: 1. It is defined only internally on GLIBC 2. By default on 32 bits it assumes off_t differs from off64_t and for 64 bits it is the contrary. On current GLIBC supported architectures it requires only MIPS64-n32 to define it. However since current kernel new port approach is make size of off_t the same as off64_t I see that all new ports will require to define it. I do not have a strong opinion which is the better approach, the only nit is I think it should not be on an installed header.
diff --git a/sysdeps/unix/sysv/linux/fallocate.c b/sysdeps/unix/sysv/linux/fallocate.c index 6a58a5f..4ec55a5 100644 --- a/sysdeps/unix/sysv/linux/fallocate.c +++ b/sysdeps/unix/sysv/linux/fallocate.c @@ -20,6 +20,8 @@ #include <sysdep-cancel.h> +#ifndef __OFF_T_MATCHES_OFF64_T + /* Reserve storage for the data of the file associated with FD. */ int fallocate (int fd, int mode, __off_t offset, __off_t len) @@ -33,3 +35,5 @@ fallocate (int fd, int mode, __off_t offset, __off_t len) return -1; #endif } + +#endif /* __OFF_T_MATCHES_OFF64_T */ diff --git a/sysdeps/unix/sysv/linux/fallocate64.c b/sysdeps/unix/sysv/linux/fallocate64.c index 8e76d6f..f4f73d5 100644 --- a/sysdeps/unix/sysv/linux/fallocate64.c +++ b/sysdeps/unix/sysv/linux/fallocate64.c @@ -35,3 +35,7 @@ fallocate64 (int fd, int mode, __off64_t offset, __off64_t len) return -1; #endif } + +#ifdef __OFF_T_MATCHES_OFF64_T +weak_alias(fallocate64, fallocate) +#endif diff --git a/sysdeps/unix/sysv/linux/posix_fadvise.c b/sysdeps/unix/sysv/linux/posix_fadvise.c index 093d707..8356bc7 100644 --- a/sysdeps/unix/sysv/linux/posix_fadvise.c +++ b/sysdeps/unix/sysv/linux/posix_fadvise.c @@ -19,6 +19,8 @@ #include <fcntl.h> #include <sysdep.h> +#ifndef __OFF_T_MATCHES_OFF64_T + /* Advice the system about the expected behaviour of the application with respect to the file associated with FD. */ @@ -46,3 +48,5 @@ posix_fadvise (int fd, off_t offset, off_t len, int advise) return ENOSYS; #endif } + +#endif /* __OFF_T_MATCHES_OFF64_T */ diff --git a/sysdeps/unix/sysv/linux/posix_fadvise64.c b/sysdeps/unix/sysv/linux/posix_fadvise64.c index 6d10558..c76d52f 100644 --- a/sysdeps/unix/sysv/linux/posix_fadvise64.c +++ b/sysdeps/unix/sysv/linux/posix_fadvise64.c @@ -56,3 +56,7 @@ compat_symbol (libc, __posix_fadvise64_l32, posix_fadvise64, GLIBC_2_2); #else strong_alias (__posix_fadvise64_l64, posix_fadvise64); #endif + +#ifdef __OFF_T_MATCHES_OFF64_T +weak_alias(__posix_fadvise64_l64, __posix_fadvise) +#endif /* __OFF_T_MATCHES_OFF64_T */ diff --git a/sysdeps/unix/sysv/linux/posix_fallocate.c b/sysdeps/unix/sysv/linux/posix_fallocate.c index fc9ac37..f9ca34b 100644 --- a/sysdeps/unix/sysv/linux/posix_fallocate.c +++ b/sysdeps/unix/sysv/linux/posix_fallocate.c @@ -18,6 +18,8 @@ #include <fcntl.h> #include <sysdep.h> +#ifndef __OFF_T_MATCHES_OFF64_T + #define posix_fallocate static internal_fallocate #include <sysdeps/posix/posix_fallocate.c> #undef posix_fallocate @@ -37,3 +39,5 @@ posix_fallocate (int fd, __off_t offset, __off_t len) return INTERNAL_SYSCALL_ERRNO (res, err); return internal_fallocate (fd, offset, len); } + +#endif /* __OFF_T_MATCHES_OFF64_T */ diff --git a/sysdeps/unix/sysv/linux/posix_fallocate64.c b/sysdeps/unix/sysv/linux/posix_fallocate64.c index 4a0a722..3a65d35 100644 --- a/sysdeps/unix/sysv/linux/posix_fallocate64.c +++ b/sysdeps/unix/sysv/linux/posix_fallocate64.c @@ -40,3 +40,7 @@ __posix_fallocate64_l64 (int fd, __off64_t offset, __off64_t len) return INTERNAL_SYSCALL_ERRNO (res, err); return internal_fallocate64 (fd, offset, len); } + +#ifdef __OFF_T_MATCHES_OFF64_T +weak_alias(__posix_fallocate64_l64, posix_fallocate) +#endif