Message ID | 1466746995-25982-1-git-send-email-ynorov@caviumnetworks.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 56310 invoked by alias); 24 Jun 2016 05:43:45 -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 56280 invoked by uid 89); 24 Jun 2016 05:43:44 -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=35, 7, Hx-languages-length:1940, errnoh, UD:errno.h X-HELO: na01-bn1-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> CC: <cmetcalf@tilera.com>, <pinskia@gmail.com>, <cmetcalf@mellanox.com>, <joseph@codesourcery.com>, Yury Norov <ynorov@caviumnetworks.com> Subject: [PATCH] fallocate: pass off_t in register pair correctly for 64-bit off_t Date: Fri, 24 Jun 2016 08:43:15 +0300 Message-ID: <1466746995-25982-1-git-send-email-ynorov@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: AM4PR02CA0018.eurprd02.prod.outlook.com (10.165.239.156) To DM3PR07MB2249.namprd07.prod.outlook.com (10.164.33.147) X-MS-Office365-Filtering-Correlation-Id: e2b86e3e-913b-4f29-a6f3-08d39bf27787 X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2249; 2:QjK8S196qj8rwdqDNa3pSidh4jGDzIGNpv6ThYdwjvBaeEyh/kJemi1Kbcu7kw2DUzB/c6Otuwume6PnzKWl1n9YbX3wkGiAnl4kgALQaF1r7uyV+XtVV9NRJofZ1fQw1zHmNGJ9xDEeB5uptt7zNgtWk7JgEv42sQM3kl42dR6wkDhpw6Ww8NIaPuVdAYqy; 3:kcDTNoig3cT2cKOROZ7qT1e0vbAcnGnynA16iTd3+mudf7hO8soLoYiHBZik0ZK2IDdrIUl/xpX3IsiKHakwWLOw9cDc37CP4X5NDqSJa3QWmtq6kqvrU4ATdZ/5pdAG X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM3PR07MB2249; X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2249; 25:V1CIux4gHKMkNJHo2VDl7z+rXh/PYMJD+rcjiHFIS9jsl/LBqwuEXrnYwZ/EJGIPQKHTJFRaRy88XT+PmyaTPPAxVvZ7KHj5OJeeZcXocAtoXIHe2RDllV8RWlfrFY8L00ehtC4sxASGhJtR+eZGzEyDPogVajxTC8Kgm/mbll+/wplVXRykKaQJP9Z1FdOcXLiALNOxrh5+wQRYpj+4K5eT/WjwmiW9g1uUcRuXK5TSeMm121T5E+mK1dr7KQYwQy+s7NxIzMSeeGHvkU91m8oT8+QcFTxqH+gDLvkFNCwncCf8Xmp5ysMS1/vgV4GFBM9YTNf58QJ6WaNLREYFtz0NjWflcACJiNJUZY9ZYKusQ12k+vMJmz07Q0k9zn10F3wPPvSZJ7NTOvKwOtMWk3z7H40vspssOJ3lJWjS5Mbd1HMPbRjqUMbZeMoe6yjzCxnTyMozXAEXfhCyf0MJUgZuGX3SX4S4kiNPza8B0UXhbMfZU4oAw3GA7pf8CcLo85daz8TfyD+v7eG9a2W7/ZyrlbBMFWtL3HcwKZUwsLKC0ZJfIgYi2YrJeuV0pTPlVohqiYJOLiaDUwPM8g0pliMn+BJH9lF4S+5HXN6t7n1UeLkqIg9lIsiPLHINiNzpeliEc2slo7afRzCMGNKL3+i5empNuQhIxI9rmXZI6oBh6/QR95WjM31/jF0SBwlh1mHSRzv8H36gtPUkVAlOJ8TNCTyS8Ex9WWvaasMkw8bFVTkoPdwLKWaLV+yn7ZCeHqLEQ7LBJ7n/jYx8atArF/CE38U+0yUXIXVYSkqoQYFD7ujgdz3mhYoFNiItUgt8UFt+urc8esIpggicUYVtNL97vOTXrK4DvnFlupIBuKo= X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2249; 20:V+d7Kj1liIJGnbIUn2DiObAsbaWj3/n8/+r2M10SLrj/htIvhvIvsxOr1MRcfidl+MHeyotdvUDm+OW3GxSc+/AjGSfEaIMd0cAtZDKeOIK86bviPnXZ7BMfPVzbk3o41o3Wd3K1rwk8i0KafVOTTL1auSN3jV35DKtwdnA2N3tMUZdE45HPx+y+hHzdxRBbtWF3Gp69y30rDnGI+gue9dem39B+c9D/Y94VmNg8ydDz8+DpCjdOb48b4q4QUfbMK6X9uIJjjjV7USK0pX+CbupJRw1tkspsCEpOB51u73SwAXH2BJjd1lzR8abrC4jWyFUGyAGAt2Djm8Sar26RghKN+4B/Q8Y8Petr+oZvW3fxwL1eeTge512clWHC+PCjy96LscDbO43loatpEa4Cp2krMwA9TfqQ4F34vDRXkBwaLb4EfgqfhKyLBnyRQOb2rTsvwJzuY3+9vLBOuKWTBh+CyjKj+pvbLWWoa9XiS6nWzMozO/VGWReZ/JyUvGZK5r1Co3VTc/dU10bPPvYyqGJlHrGkEiYkubOKldeYJq+bmUNMDhvcR2GSGOQvGLaWZUZ7S2W5TDkCsduD+pCYPRFw9igOl+dczBs2yrM0KWY= X-Microsoft-Antispam-PRVS: <DM3PR07MB224945EF7FBEAC3C7CB06C4AEE2E0@DM3PR07MB2249.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(250305191791016)(22074186197030); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM3PR07MB2249; BCL:0; PCL:0; RULEID:; SRVR:DM3PR07MB2249; X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2249; 4:2hskC7PMjYU81v+6+b3bE9SjFB5lINDQWx6c7VheZGcGPJ+GXFy8AjvBdTEaQUNStpgHZDboGIYSBXwIG+GtXF7zNUkbHwM5BypNiaiwdH2Rwf0QgjAd3ocwUfPYQJTFZOIi/wPsltSdiGxgxZ5bVZUpobJsCF/Achus75O7ICDRBkjWeDMzyyu6itNoqxIlnfhnNc/JM3i/HNGNGe4CF1DopRxymQ0vfVmWcNJv1Vx1iIC/umv3BsSzqYeUR5j6o4UNCujcVcRIWm+FMNXdOMGVxTRqefpOIQ/Fjo8ys/RETXFz67fMOaY6Qo8k7wtceIYjSW+t/He7OadsJ5RbW5eQmzJXIJHgJva1ClGeIrwfZJ3oMB2nZBN8n4cMjBJE4estFXOS3vDYWb7H+UL+rt1mV7TYH+eBQBXt1PyumP3URElU74Nk/4U6b1xVRhm5 X-Forefront-PRVS: 0983EAD6B2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(189002)(199003)(92566002)(3846002)(586003)(6116002)(36756003)(50226002)(66066001)(77096005)(47776003)(7846002)(33646002)(4326007)(97736004)(2906002)(19580395003)(19580405001)(68736007)(101416001)(229853001)(81156014)(2351001)(4001430100002)(50466002)(110136002)(15975445007)(107886002)(48376002)(7736002)(8676002)(105586002)(76506005)(106356001)(50986999)(81166006)(42186005)(5003940100001)(189998001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM3PR07MB2249; H:localhost; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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; DM3PR07MB2249; 23:pxtL5jdvkaeTA04C4ZP76wY8HnyNL7oYu/SMBUlQj?= =?us-ascii?Q?rHaY1ay0nW7VTyrzAnCzKJ1iqElwvRQ5pMraLTl0s2Zo0MRCXpFwtvvRvDt0?= =?us-ascii?Q?T0WZLkdy0VIIt8wJhV9/VFtwCgIm7ikeSd+UMlsNpcKVSLEn6jk9rn3ZGGoM?= =?us-ascii?Q?LjUfJIdPIVrxaHiGXcmTKNjeCE2r12A4ORIKnm6uCSEL2OtjvTAzoB+yblYk?= =?us-ascii?Q?CJaphiRjzYKCWa4WQF6mHCL3LIy8Fthw3L9h2VypqbKrexf+d6b6YELJmAd+?= =?us-ascii?Q?E8UQc1abc4Ej/jQzl7BChArk627pxbb7O4tu/IPkVMC0kRfOK8bQDbg6hiFn?= =?us-ascii?Q?ayXnCdYhU5DBrq/SdMIzrjXDEMLhUb/muTrrAJ4DEHNWL0Xf3zHAqoTOb7qj?= =?us-ascii?Q?7GT3m5fV41AAvRvdRkBWH/lVMmTYB57XrGOVEIeEW1080hbsen4k7VIYfn0u?= =?us-ascii?Q?nGSc69FjZnHqcl65brgj6GpQmnWtT9S8LgbSg38mLQIARDvG7xwYwY8N2zMt?= =?us-ascii?Q?Lnq/Qfb+XdVJ/6+clXMB4dIRM2HnVd4f3WlPxrxW6/ClZ1TusdfQxE/6TWVt?= =?us-ascii?Q?1A4SP3KH1BKxXtN4OvkrOXmpkyDhEegnlFKmsw7QGBep4aomhWSPIEysr3kJ?= =?us-ascii?Q?Rh5cq85kJufTx3n/wbG71wH95e119C4ViiaeYIWArLjjGwD1s/+OJs1xc2/f?= =?us-ascii?Q?/kjFQgi4yMKO5GuDKnts75Hp3iPA0r9ht5RdVLKhvzRgqWUulkkUSzVKt0/Y?= =?us-ascii?Q?9t+K9uQlyr9HCS6wJMzRAxRY5HYwsBh7YXe/gxO28aVWkoq2bxfJD8JSAie0?= =?us-ascii?Q?Tp1XdLbxN8OM1qBTdtDHEqeK/KwD/3SeKFUmaod1KjcAhmamxRyOsPwH4zSf?= =?us-ascii?Q?P/FsESmTRRYffyMLm+tEZyoWXZIVWEmXU44doqnXy7tKWN/cLGitMV56PoLT?= =?us-ascii?Q?XRvE8AUyOTBh33VBXDuSJB3JKXhQFikrxqLy0CqShaECvjOkYAS4QnM3TCT8?= =?us-ascii?Q?01YExWd6JHn2Hv/kNYGu8sCV+PJA1x5axWZHudOgYQuoqP/y/m+iP8gq7Dpn?= =?us-ascii?Q?gapD8wQoKOc6SOJyMPSkXR0S7M0tUl3fNx9gkxia98NoYKlLE+Q3V/z7Pauq?= =?us-ascii?Q?ff0kMsUOOM=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM3PR07MB2249; 6:LTFbdQzIww4c3IEqu/uw6e6efGlsAM+IPVDZuYKoJ009I+RE2PKkyU50Jp7P8hHoUcIiXqDCEjknsW7Tjnyf7YonulduPAQWxkHU8axp5e1VXxSgIoexiZF2+ui5/xtfHPssop/yF/PNIuHrVeESGqaX7EvbD1yxRTcd+FZXVZUR7b6SEo1NKdw818gWBDDpHHYCtmp3q+D25LJVf6Sl+mYzxblwgCk/vL82Xv89pXwrSpDWB90FNxWJXfZwXlFrZyfhWlhjvD5hg+s3laq+bcaby7up+OOMuoDkPB3CUm79ZeKLCPXL6pKxQbcrTWDB; 5:Cxdxk5uUW0mS7sjhCKgFohtYo9zwGt+9tCA0kJi7Z3utOyt7ZEJPnPMKiwLXdMGoBt0jAQGKhuPAmdkmQO3mhpSJ4rKms3MvqrpxB3XiI9wS57HGWlBYnv4nWNyuPvl2bbCHNOvYqG6OFhO0SlRHxg==; 24:X8B1qAfyKl1ab9hIER+LX1YTtwBA1sNG5rEWfsqKPa6JDs39Lhlr7/m5tNOFbJDhuw+q0AH3oJZLbWkDHAShTfDDLsZKVgvjPdHGEibVR9k=; 7:S5lPPgZNUOOlREpdTNfu0uh34mGLzjTh0/aadGQ+C7VsENEXykYjyCT25LZRkGNgh78t1HII6PqnLm5InbHKUouH1nLR059DZn3XQLyLCkPaiRbZMaHPna+dv4kmT3qG1qoSIMV6MwaXbfADemNUC1dOC4AjOVnHt43SDyJrE28dOUchWWsA1U1S9z2rP5o7GtWkJVr/W1RSOBMcxePRd+PzvREVIglJxQLSVB5e2H+VSuRejNo//VhK2fnsDrMLOu1+f3wJLLs5XfWNhh20Wg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2016 05:43:27.5438 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR07MB2249 |
Commit Message
Yury Norov
June 24, 2016, 5:43 a.m. UTC
sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating
register pair from 32-bit signed value:
LONG_LONG_PAIR (val >> 31, val)
It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t,
so this hack doesn't work for them. In this patch, fallocate handler is taken from
fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T.
The other option to fix it is to introduce macro that creates the pair correctly
for both 32- and 64-bit off_t, like this:
#ifndef __OFF_T_MATCHES_OFF64_T
#define CREATE_OFF_PAIR(val) ((val) < 0 ? (-1) : 0 , (val))
#else
#define CREATE_OFF_PAIR(val) ((val) >> 32, (val))
#endif
If 2nd option is looking more appropriated, I can prepare the patch for all
affected syscalls.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
sysdeps/unix/sysv/linux/fallocate.c | 3 +++
sysdeps/unix/sysv/linux/fallocate64.c | 4 ++++
2 files changed, 7 insertions(+)
Comments
On Fri, 24 Jun 2016, Yury Norov wrote: > diff --git a/sysdeps/unix/sysv/linux/fallocate.c b/sysdeps/unix/sysv/linux/fallocate.c > index 6a58a5f..8a7149f 100644 > --- a/sysdeps/unix/sysv/linux/fallocate.c > +++ b/sysdeps/unix/sysv/linux/fallocate.c > @@ -15,6 +15,7 @@ > License along with the GNU C Library; if not, see > <http://www.gnu.org/licenses/>. */ > > +#ifndef __OFF_T_MATCHES_OFF64_T > #include <errno.h> Does the header defining this macro get included implicitly from the command line? If not, you need to include appropriate headers before testing it.... (It might be a good idea, before doing anything more based on such macros, to do a preparatory patch series converting them to 0/1 form with #if used, instead of undefined/defined with #ifdef, so that -Werror -Wundef detects any cases where required headers are not included.)
On 24 Jun 2016 08:43, Yury Norov wrote: > sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating > register pair from 32-bit signed value: > LONG_LONG_PAIR (val >> 31, val) > > It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t, > so this hack doesn't work for them. In this patch, fallocate handler is taken from > fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T. what ABIs exactly are you referring to ? why is this change specific to fallocate ? seems like this argument could be made about any of the funcs that operate on off_t's. what about posix_fallocate ? posix_fadvise ? > The other option to fix it is to introduce macro that creates the pair correctly > for both 32- and 64-bit off_t, like this: if off_t & off64_t are the same size, we don't want duplicate symbols that do the same thing. -mike
On Fri, Jun 24, 2016 at 04:30:23AM -0400, Mike Frysinger wrote: > On 24 Jun 2016 08:43, Yury Norov wrote: > > sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating > > register pair from 32-bit signed value: > > LONG_LONG_PAIR (val >> 31, val) > > > > It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t, > > so this hack doesn't work for them. In this patch, fallocate handler is taken from > > fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T. > > what ABIs exactly are you referring to ? AARCH64/ILP32. It would be any modern 32-bit API, as off_t should be 64-bit for them > why is this change specific to fallocate ? seems like this argument > could be made about any of the funcs that operate on off_t's. what > about posix_fallocate ? posix_fadvise ? Because it's RFC. If this one is OK, I'll prepare correct patch for all affected functions. I also wrote this small patch to ask what way is more preferable - with macro, or with redirection. > > The other option to fix it is to introduce macro that creates the pair correctly > > for both 32- and 64-bit off_t, like this: > > if off_t & off64_t are the same size, we don't want duplicate symbols > that do the same thing. > -mike So it 1st version is OK, I'll prepare full patch with all needed redirections. Yury.
On Fri, Jun 24, 2016 at 07:35:09AM +0000, Joseph Myers wrote: > On Fri, 24 Jun 2016, Yury Norov wrote: > > > diff --git a/sysdeps/unix/sysv/linux/fallocate.c b/sysdeps/unix/sysv/linux/fallocate.c > > index 6a58a5f..8a7149f 100644 > > --- a/sysdeps/unix/sysv/linux/fallocate.c > > +++ b/sysdeps/unix/sysv/linux/fallocate.c > > @@ -15,6 +15,7 @@ > > License along with the GNU C Library; if not, see > > <http://www.gnu.org/licenses/>. */ > > > > +#ifndef __OFF_T_MATCHES_OFF64_T > > #include <errno.h> > > Does the header defining this macro get included implicitly from the > command line? If not, you need to include appropriate headers before > testing it.... (It might be a good idea, before doing anything more based > on such macros, to do a preparatory patch series converting them to 0/1 > form with #if used, instead of undefined/defined with #ifdef, so that > -Werror -Wundef detects any cases where required headers are not > included.) > > -- > Joseph S. Myers > joseph@codesourcery.com Thank you, I'll #include <sys/types> for it.
On 24 Jun 2016 11:52, Yury Norov wrote: > On Fri, Jun 24, 2016 at 04:30:23AM -0400, Mike Frysinger wrote: > > On 24 Jun 2016 08:43, Yury Norov wrote: > > > sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating > > > register pair from 32-bit signed value: > > > LONG_LONG_PAIR (val >> 31, val) > > > > > > It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t, > > > so this hack doesn't work for them. In this patch, fallocate handler is taken from > > > fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T. > > > > what ABIs exactly are you referring to ? > > AARCH64/ILP32. It would be any modern 32-bit API, as off_t should be > 64-bit for them ignoring ILP32 ABIs (which are running on native 64-bit hardware and have full access to the 64-bit registers), no new 32-bit port is being defined with 64-bit off_t types. they follow existing style where LFS is used. whether we want to change all 32-bit ports to be LFS-enabled by default is a different question ... we'd still want them to be consistent. -mike
On Friday, June 24, 2016 12:15:52 PM CEST Mike Frysinger wrote: > On 24 Jun 2016 11:52, Yury Norov wrote: > > On Fri, Jun 24, 2016 at 04:30:23AM -0400, Mike Frysinger wrote: > > > On 24 Jun 2016 08:43, Yury Norov wrote: > > > > sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating > > > > register pair from 32-bit signed value: > > > > LONG_LONG_PAIR (val >> 31, val) > > > > > > > > It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t, > > > > so this hack doesn't work for them. In this patch, fallocate handler is taken from > > > > fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T. > > > > > > what ABIs exactly are you referring to ? > > > > AARCH64/ILP32. It would be any modern 32-bit API, as off_t should be > > 64-bit for them > > ignoring ILP32 ABIs (which are running on native 64-bit hardware and have > full access to the 64-bit registers), no new 32-bit port is being defined > with 64-bit off_t types. they follow existing style where LFS is used. > > whether we want to change all 32-bit ports to be LFS-enabled by default is > a different question ... we'd still want them to be consistent. I've been pushing the move for 64-bit off_t for both RISC-V and ARM64/ILP32, mainly because it seems like the right thing to do (the kernel has stopped supporting 32-bit off_t for new architectures many years ago), and there were no technical arguments[1] in favor of 32-bit off_t emulation in glibc beyond the fact that someone has to do the work to implement the new default once. If you feel strongly about it for some reason, I guess we can go back to defaulting to 32-bit off_t on aarch64/ilp32, but I absolutely agree that we want to be consistent here, and then we should do the same on RISC-V. Arnd [1] actually one argument in favor of 32-bit off_t would be to wait until the kernel can also do 64-bit time_t on all architectures, and then change both at the same time for all architectures merged after that point.
diff --git a/sysdeps/unix/sysv/linux/fallocate.c b/sysdeps/unix/sysv/linux/fallocate.c index 6a58a5f..8a7149f 100644 --- a/sysdeps/unix/sysv/linux/fallocate.c +++ b/sysdeps/unix/sysv/linux/fallocate.c @@ -15,6 +15,7 @@ License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ +#ifndef __OFF_T_MATCHES_OFF64_T #include <errno.h> #include <fcntl.h> #include <sysdep-cancel.h> @@ -33,3 +34,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